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q fphiet cletT Erfi nduna 

Die Erf indung bezieht sich auf ein Multiprozessorcomputersystem 
und insbesondere auf Einrichtungen. die bei der Entwicklung von 
Computerprogratnmen fur solche Systeme helfen. 

w-inrRram ^'^ Erfindunq 

Coraputerunterstutzte softwareentwicklungs software (CASE) bzw. 
Sof twareentwicklungseinrichtungen unterstutzen Cornputerprogram- 
mierer oder Systementwickler beim Planen, Entwickeln und Testen 
eines Computerprogranmis . 

Traditionell wurden die Schritte. die zum umsetzen eines 
computerprogratnms notwendig sind, tnanuell ausgefuhrt. Entwick- 
lungsteams. folgten einer Zahl von diskreten Schritten. urn ein 
brauchbares Anwendungsprogramm von einer ursprunglichen Idee aus 
zu entwickeln. 

Die Analyse beginnt mit dem manuellen Entwickeln eines Modells, 
in dem ein Problem von einera Computer gelost werden kann. 
Entwicklungsteams ermitteln die Bedurfnisse des zukunftigen 
Benutzers und die Eigenschaf ten, die das Computersystem besitzen 
sollte, urn diese Anforderung zu erfullen. 

in der technischen Planungsphase der Entwicklung beginnen 
Entwickler damit, zu definieren, wie das Anwendungsprogramm auf 
einem gegebenen System aufgebaut wird. Sie bestimmen manuell die 
benotigteii verfahrens- und Datenelemente, und wie die Daten und 



verfahren zusanimengesetzt werden, um die Sof twarelosung auszu- 
bilden. In dleser Phase sind die Datenmodellbildung und die 
ProzeSmodellbildungdie beiden Hauptaufgaben. 

Mit dem Basisplan des modellierten Programms beginnen Entwickler 
dann die Aufgabe der Eingabe des Codes des Programms. Computer- 
progratnme warden im aULgetneinen in hoheren Programmiersprachen, 
wie beispielsweise BASIC, C, COBOL, FORTRAN oder PL/l geschrie- 
ben. Die Aufgabe, die theoretischen Planung einer Anwendung auf 
einen Arbeit scode zu reduzieren, ist eine muhsame Aufgabe, die 
viele Mannstunden erf order t . Erf ahrung in der zur Entwicklung 
des Programms verwendeten Progratnmiersprache ist erf orderlich. 

Mit detn geschriebenen Code ist es das nSchste Problem des 
Entwicklungst earns, das Prograram hinsichtlich Syntsucf ehlern zu 
entst6ren, und dann das Programm zu testen, urn f estzustellen, ob 
die Anwendung die gewunschten Funktionen ausfiihrt. Typischer- 
weise erfordert die Entstor- und Testphase, daS der Programmie- 
rer das Programm auf der Codeebene auswertet . 

Die Entwicklungsaufgaben des Programmierers warden anspruchs- 
voller mit der Verwendung einer Architektur von Multiprocessing- 
systemen, 

Traditionell gab es zwei grundlegende Hardwarekonf igurationen, 
die beim Aufbau von Cpmputersystemen fur eine Mehrzahl von 
Verwendem eingesetzt wurden. In einer Konf iguration wird die 
gesamte Verarbeitung des Systems von einem groEen "Mainframe"- 
Computer ausgef uhrt . Jeder Benutzer greift auf dieses System 
uber nicht-verarbeitende Endgerate zu. 

Ein Netzwerksystem ist die zweite traditionelle Hardwarekonf igu- 
ration. Ein Netzwerk besteht aus einer Anzahl von einzelnen 
verarbeitenden Einheiten, die zusammengeschaltet sind, um das 
gemeinsame Verwenden von Daten und Software zu ermoglicheh. 
Dabei kann es zusatzliche Prozessoren geben, um die zentrali- 
sierte Datenbasis einer Gruppe zu pflegen, und zusatzliche 



prozessoren konnen der Auf rechterhaltung des Betriebs des 
Systems zugeordnet sein. Die verwendung eines Netzwerks von 
Prozessoren, die jeweils einem spezifischen Aspekt des Computer- 
systems zugeordnet sind, ist die Essenz des Multiproces sings . 

Das Zunehmen der Verwendung von Multiprocessingsystemen kann auf 
die Starke Verbreitung und Entwicklung von leistungsf ahigen 
"Mikro-" bzw. "Personal- "Comput em (PC's) zuruckgefulirt werden. 
In gewissen Grenzen kaim ein PC viele derselben Verarbeitungs- 
aufgaben ausfuhren, die Mainframe- bzw. Minicomputer ausfuhren. 
Ein PC kann diese Aufgaben jedoch mit einer erheblichen Einspa- 
rung an Anweisungen ausfuhren, die von dem Computer ausgefuhrt 
und in Millionen Anweisungen pro Sekunde, "MIPS", gemessen 
werden. Weiterhin ist ein PC ungleich einem Mainframe- System 
einem einzelnen Benutzer zugeordnet. Ein effizientes Multi- 
proces singsystera fdrdert die gemeinsame Verwendung von Daten und 
die verwendung von bestimmten PC's fur so viele Aufgaben wie 
mSglich. 

Bei Multiprozessorsystemen kann eine Anwendung auf mehr als 
einem Prozessor ausgefuhrt werden. wenn verschiedene Teile eines 
Anwendungsprogramms auf getrennten Prozessoren ausgefuhrt 
werden, ist die Anwendung "verteilt" . Verteilte Verarbeitung 
kann entweder in einer seriellen Sequenz oder parallel ausge- 
fuhrt werden. 

Die gleichzeitige Ausfuhrung eines Programms auf vielen Prozes- 
soren ist parallele Verarbeitung. Die sequentielle Ausfuhrung 
eines Programms uber verschiedene Hardwareumgebungen ist seri- 
elle bzw. "kooperative" Verarbeitung. 

Die Moglichkeit des Multiprocessings stellt neue Herausforderun- 
gen an Computersystementwickler . Wahrend in einer Mainframe- 
Otngeburig alle Teile des Programms fur eine einzige Utngebung 
entwickelt wurden, konnen die Entwickler bei Multiprocessing- 
systemen die jeweilige Umgeb\ing wahlen, in denen spezielle 
Aspekte eines Programms laufen werden. 



Obwohl diese Freiheit bei der Verteilung des Progratnms in 
hochef fektive Anwendungen resultiert, mussen die Progratnmierer 
jetzt Programme konstruieren, die zur Ausfuhrung in vielen 
Hardwareumgebungen ausgelegt sind. 

Die Aufgabe des Programmierens von Multiprocessingsystemen 
schlieBt schwierige Probleme des Austauschens von Daten zwischen 
verschiedenen und inkompatiblen Umgebungen ein. Zum Beispiel ist 
eine Datei, die in einem PL/l-Forcnat gespeicherte Daten enthalt, 
nicht von einem Programm lesbar/ daE in einer anderen Sprache, 
wie beispielsweise C Oder COBOIi geschrieben ist. Bin Prograramie- 
rer muE spezielle Software entwickeln, um die Koraraunikationspro- 
bleme zu handhaben, die Multiprocessingsystemen inh&reilt sind. 

ZusStzlich muS ein Prograramierer die verschiedenen verteilten 
Programme in der Sprache einprograramieren, die von der jewei- 
ligen Umgebung unterstutzt wird. Zum Beispiel mussen, falls die 
PC-Prozessoren nur Programme unterstutzen, die in der Sprache C 
geschrieben sind, jene Teile des Programms in C sein. Gleich- 
zeitig kann es sein, daE die anderen Teile des Programms, wie 
beispielsweise die auf dem Mainframe, in einer anderen Program- 
miersprache geschrieben sein mussen. 

Das Programmieren in einer Multiprozessorumgebung ist sehr 
komplex und zeitaufwendig. Die Personalanf orderungen zum Ent- 
wickeln einer Anwendung in einer Multiprozessorumgebung allein 
kdnnen die Aufgsd^e wegen der Kostenseite unerschwinglich machen. 
CASE-Einrichtungen wurden entwickelt, um einige der Belastungen 
zu verringem, die die Multiprocessingarchitektur dem Program- 
mierer auf erlegt hat . 

Traditionell ermoglichen CASE-Einrichtungen einem Benutzer, ein 
logisches Konzept fur ein Programm in einer h5heren Sprache 
einzugeben, das dann in einen Code in einer jeweiligen 
Computersprache ubersetzt wird. Die derzeit verfugbaren CASE- 
Einrichtungen geben dem Systementwickler jedoch kein komplettes 
einheitliches System fur die Planung, die Umsetzung und die 



PElege einer sof twareanwendung an die Hand. Die derzeitigen 
Einrichtungen unterstutzen nicht die Entwicklxing eines Progrannns 
an einem zentralen Ort, wobei ein ubersetzter Code erzeugt \and 
an verschiedene Uragebungen verteilt wird. Die derzeitigen CASE- 
Tools stellen auch kein Verfahren zur Wiederverwendung von 
Teilen von zuvor entwickelten Anwendungen bereit, die in der in 
der Entwicklung befindlichen Anwendung verwendbar sein konnen. 
Die derzeitigen CASE -Einrichtungen stellen keine geeigneten 
Test- und Entstor-Tools bereit. 

Eines der Dilemmas beim Entwickeln eines CASE-Tools ist, daS 
sich die Ausgabe, die dera Benutzer fur die Planungsphase des 
Projekts zur Verfugving gestellt werden muS, sich von der Ausgabe 
\interscheidet, die spSter. wahrend der umsetzung ben6tigt wird. 
Fruhe CASE-Tools neigten dazu, die unterstutzung einer dieser 
beiden Kategorien von Aktivitaten zu betonen \ind die andere zu 
vernachlassigen . 

Bei den fruheren planvings-orientierten CASE-Tools war die 
Ausgabe einer Entwicklerarbeit mit dem Tool ein Bild. Womit ein 
Entwickler endete, war Dokumentation, die verwendet werden 
konnte, urn tatsachlich ein System zu erzeugen, aber nicht das 
tatsachliche System selbst. ZusStzlich mufite der Entwickler, 
falls wShrend der omsetzungsphase ein Anwender einen Grund 
aufdeckte, um irgendeinen Aspekt des Progratnms zu andern, 
zuruckgehen und manuell die Anderung identif izieren und die 
Dokumentation aktualisieren -- die Dokumentation war nutzlos, 
solange sie nicht standig aktualisiert wurde. Die tatsachliche 
Umsetzung des Systems sowie jegliche Anderungen wurden unter 
verwendung traditioneller Verfahren ausgefuhrt. Der einzige 
Vorteil bei der verwendung eines Planungs- orient ierten CASE- 
Tools war, dafi es annehmliche vollstSndige Dokumentation 
erzeugte, die bei der pianung in den fruhen Stadien wirklich 
hilfreich war. 



Die zweite Familie der CASE-Tools war umsetzungsorientiert . 
Diese CASE-Tools erlaubten es einem Entwickler, ein Schaubild 



eines vollstandigen Modells zu zeichnen, aber hicht eines Stuck 
eines Moduls. Im wesentlichen konnte der Entwickler ein Bild des 
Modells erhalten, an dem der Entwickler gerade arbeitete. Wenn 
der Entwickler das Modell in das Mainframe- Endlager entlud, 
ersetzte das Modell das Modell, das dort jeweils bereits 
gespeichert war. Die tatsachliche Dokumentation dieser Systeme 
war primitiv und unflexibel. 

In einem Artikel uberschrieben "An Approach to the Support of 
'Software Evolution" von I. Soiranerville und R. Thompson^ Computer 
Journal, Vol. 32, 0.5, Oktober 1989 ist ein System zur Unter- 
stutzung aller Stadien des Sof twarelebenszyklus beschrieben, 
Insbesondere unterstQtzt das System die Koramunikation und 
Dokumentation der Struktur des Sof twaresystemprojekts, wahrend 
es sich entwickelt . . Das System erzeugt jedoch keine tatsach- 
lichen Computerprogramme . 

Zusamme nfassuna der ErfindunQ 

Die vorliegende Erfindung ist eine CASE-Einrichtung, die ein 
Verfahren und eine Vorrichtung zum Planen, Umsetzen und Pflegen 
von Sof tware bereitstellt, welche in mehrteiligen Hardware- 
umgebungen ISuft --in einer Verteilung, die fur den Endbenutzer 
transparent ist . 

Ein Aspekt dieser Erfindung ist ein Verfahren zur Modellbildung 
der Datenstruktur und der Daten, die von dem Programm verwendet 
werden, durch eine Eleiiiente-Beziehungen-Modelliertechnik, 

Ein anderer Aspekt ist eine relationale Datenbank, in der Daten 
gemafi dem Elemente-Beziehungen-Modell gespeichert werden. 

Ein anderer Aspekt ist die hohere Regelprache, in der die Logik 
eines Programms in hochmodularer Form festgelegt werden kann und 
die die Einfachheit der wiederverwertbarkeit f 6rdert . 

Die Erfindung stellt die Moglichkeit zur Brzeugung von CJuellcode 



fur das Prograinm in einer Sprache bereit, die von den verschie- 
denen Hardwareelementen in dem Multiprocessingsystem iinterstutzt 
wird, unter Verwendung des Elemente-Beziehungen-Modells und der 
Module der hSlieren Rege 1 sprache . 

Um den Quellcode des Prograinms zu erzeugen, stellt die Erf indung 
Grundprograramelemente zur Verfugung, um das Progratnm in einer 
Multiprocessingumgebung auszuf uhren . Diese Prograramkomponenten 
und die niederen Routinen werden mit den Modulen der Regel- 
sprache und den Datentypelementen kotnbiniert , um das Progratnra zu 
erzeugen. 

Die Erf indung stellt weiterhin Einrichtungen bereit zum Vertei- 
len, Zusatnmensetzen und Koitqpilieren des Progratnms, das unter 
Verwendung der CASE-Einrichtung der vorliegenden Erf indung ent- 
wickelt wurde, sowie zum Testen lind Modifizieren des Programms. 

Kurzbeschreibung der Zeich nungen 

ist eine Darstellung eines dreifach unterteilten 
Computersys terns . 

ist eine zeichnerische WiedergaODe eines Prograram- 
elements gemaS der vorliegenden Erf indung. 

ist eine zeichnerische Wiedergabe eines beispielhaf ten 
Entwicklungswerkbankmoduls, das in einer PC-Hardware- 
umgebung angeordnet ist. 

ist eine zeichnerische Wiedergabe einer beispielhaf ten 
Elementbeziehung gemaB der vorliegenden Erf indung. 

ist eine zeichnerische Wiedergabe einer beispielhaf ten 
Elementzerlegung gemSS der vorliegenden Erf indung. 

Fig. 5+6 sind zeichnerische Wiedergaben des Elemente-Bezie- 
hungen- Model Is fur Anwendungsprogramme gemaE der 



Fig. 1 



Fig. 2 



Fig. 2a 



Fig. 3 



Fig. 4 
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vorliegenden Erfindung. 

Fig. 7 ist eine zeichnerische WiedergsQ^e des ProzeSf lusses 
fur ein beispielhaf tes Prograiran unter verwendung der 
Elemente-Beziehungen-Modelliertechniken gemaS der 
vorliegenden Erfindung. 

Detiaillie r'tiQ Beschreibung der Erfindung 

A. Hardware , 

Eine typische Hardwarekonf iguration fur ein Computersystem, das 
die CASE-Einricht\ing der vorliegenden Erfindung verwendet, ist 
in Fig, i gezeigt. Die Figur beschreibt ein "dreifach unter- 
teiltes" Computersystem, das nach den drei unterschiedlichen 
Typen der vemetzten Prozessoreri benannt ist: dem Mainfrarae- 
Cotirputer 1, z. B. einera IBM 3090, einem Mini- oder Supermini- 
Computer 2, z, B. einem IBM S/88 oder Stratus, und einer 
Mehrzahl von Mikro-Con^uterarbeit splat zen 3, z. B. IBM PC 
Arbeit splatzen. Ein System, das die CASE-Einrichtung der 
vorliegenden Erfindung verwendet, ist nicht nur auf diese 
Hardwarekonf iguration beschrankt. Zum Beispiel kann eine 
ahnliche CASE-Einrichtung aufgebaut werden, um einen Code zu 
entwickeln, der in einer zweifach imterteilten Umgebung verteilt 
wird, wie beispielsweise in einem System, das nur einen Main- 
frame und PC-Arbeitsplatzen verwendet, oder in einer zweifach 
unterteilten Umgebung, die einen Mainframe-Computer und einen 
Minicomputer aufweist, wobei diese beide von nicht- intelligenten 
Endgeraten zugSnglich sind. Die CASE-Einrichtung kann zuge- 
schnitten werden, um zu jeder Hardwarekonf iguration zu passen. 
Die Grundprinzipien der Codeerzeugung , der Pflege der 
zentralisierten Datenbank und der Verwendung der auf Regeln 
basierenden Sprache, die in Verbindung mit anderen Entwick- 
lungstools verwendet wird, welche von dieser Erfindung aufge- 
zeigt werden, sind dieselben, unabhangig von einer spez^iellen 
Hardwarekonf iguration . 

Die Flexibilitat bezuglich der Hardwarekonf iguration ist ein 



vorteil der CASE-Einrichtung gemaS der vorliegenden Erfindung 
gegenuber solchen CASE-Einrichtungen, die derzeit verfugbar 
sind. Die CASE-Einrichtung der vorliegenden Erfindung ermoglicht 
flexible architektonische Konzepte durch Erzeugung einer zentra- 
lisierten Datenbank, genannt Endlager, wo das Konzept und die 
Iiogik des Progratnmoduls gespeichert wird und von wo der liber- 
setzte Code automatisch an die verschiedenen Hardwareumgebungen 
verteilt wird. 

Typische Prozessoren, die fur jede der Stufen bei der beispiel- 
haften dreifach unterteilten Hardwarekonf iguration bevorzugt 
sind, sind der IBM-Mainf rame, der unter der Handelsmarke "Modell 
3090" verkauft wird und auf dem das IBM NVS/XA-Betriebssystem 
lauftf der Stratus Mini -Computer, der unter der Handelsmarke 
"Modell XA 2000" verkauft wird und auf dem das Stratus Computer, 
inc. VOS Betriebssystem lauft; und der IBM Mikro-Cott^juter , der 
unter der Handelsmarke "PS2" verkauft wird und der das Microsoft 
Corporation Betriebssystem ausfubrt, das unter der Handelsmarke 
"MS-DOS" verkauft wird. (Fur weitere inf ortnationen zu diesen 
Prozessoren und ihren Betriebssystemen wird der Leser auf die 
folgenden Publikationen verwiesen, die hiermit ausdrxicklich 
durch Bezugnahme inkorporiert sind: "IBM System/370 Biblio- 
graphy", Dokument Nr. 6024448; und "Introduction to VOS" der 
Stratus Computer, Inc., Dokument Nr. R 0001.) 

B. Rlemente der CASE-EinrichtuncT 

Die CASE-Einrichtung der vorliegenden Erfindung weist eine 
Anzahl von programmierten Elementen auf, wie sie in Fig. 2 
dargestellt sind: ein Endlager 4; eine Regelsprache 6; einen 
Kommunikationsmanager 8; eine Test- /Ents tor einrichtung 10; eine 
PC-Benutzer-Schnittstelleneinrichtung 12, einschlieSlich eines 
Kegel zeichners 30; eine Arbei t splat zversorgung, die einen 
Arbeitsplatzmanager 14, einen Fensterzeichner 16 und Arbeits- 
platzumwandlxing 18 auf weist; eine Dokumentationseinrichtung 20; 
und einen Systemeerzeuger 22 einschliefilich eines Codeerzeugers 
24, eines Datenzugangserzeugers 26 und einem Systemzusammen- 
bauers 28. Obwohl die von der CASE-Einrichtung erzeugten 
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Programme zentral gespeichert werden, konnen die Programm- 
elemente des CASE- Systems in jeder der Hardwareumgebungen 
angeordnet sein, die bei einer Konf iguration verwendet werden. 

Das Endlager 4 ist eine zentrale Datenbank, die verwendet wird, 
um alle Inf ormationen uber samtliche Anwendungsprograrame zu 
speichem, die mit der CASE-Einrichtung der vorliegenden Erf in- 
dung erzeugt werden. Das Endlager 4 kann in irgendeiner 
Hardwareumgebung existieren^ die eine libliche relationale 
Datenbank unterstutzt. Zum Beispiel kann das Endlager 4 in der 
dreifach unterteilten Umgebung, die in Fig. 1 gezeigt ist, auf 
dem Mainframe Computer 1 existieren, unter Verwendung des IBM- 
Systems DB2 far das Verwalten relationaler Datenbanken. 

Zum Zweck einer bevorzugten Ausfuhrungsf orm dieser Erf indung ist 
es bevorzugt, daS das zentrale Endlager in der Mainframe- 
Umgebung angeordnet ist.und dalS die relationale IBM-Datenbank, 
die unter der Handel smarke "DB2" verkauft wird, verwendet wird. 
{Fiir Hint ergrundinf ormationen zu DB2 wird der Leser auf die 
folgenden IBM-Publikationen verwiesen, die hiermit ausdrucklich 
durch Bezugnahme inkorporiert werden: "IBM DATABASE 2 Intro- 
duction to SQL" (Dokument Nr. GC2 6-4082) ; "IBM DATABASE 2 
Reference" (Dokument Nr. SC26-4078) ; "OS-VS2 TSO, "CommcUid 
Language Reference" (Dokument Nr. GC28-0646) ; "TSO Extensions 
Command Language Reference" (Dokument Nr. SC28-1307),- 
" Interactive System Productivity Facility/ Program Development 
Facility for MBS: Programs Reference" (Dokument Nr. SC34-2089) ; 
"Interactive System Productivity Facility/Program Development 
Facility of MVS: Dialogue Management services" (Dokument Nr. 
SC34-2137) und "DB2 Application Programming Guide for TSO and 
Batch Users" . ) 

Die in dem Endlager 4 gespeicherten Inf ormationen schlieSen 
Modelie ein, die von der vorliegenden Erf indung bereitgestellt 
werden, um die Grundlage fur ein Anwend\ingsprogramm und logische 
Module hoheren Niveaus zu bilden, die von der vorliegenden 
Erfindung fur die Verwendung bei der Erzeugung eines ausfuhr- 
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baren Programms def iniert werden, wie deutlich warden wird. Fur 
jedes Progranim werden ein Datenmodell und ein Verarbeitungs- 
tnodell durch Verwendung eines Elemente-Beziehungen-Modellier- 
systems entwickelt und in dem Endlager 4 gespeichert. Die 
logischen Module hdheren Niveaus, die in dem Endlager 4 
gespeichert werden, sind in einer Regelsprache geschrieben, die 
von der vorliegenden Erfindung wie unten beschrieben definiert 
wird. Die Inf ormationen sind umgebungsabhangig und strukturiert , 
um einen hohes MaS an wiederverwendbarkeit bereitzustellen. 

Programmierer geben Inf ormationen unter Verwendung einer 
ixblichen Datenbanksprache, die von der Hardware unterstutzt 
wird, in das Endlager 4 ein. Zum Beispiel, wenn das Endlager 4 
aus einer IBM DB2-Datenbank aufgebaut ist, wurde ein Programmie- 
rer die DB2 Structured Query Language, SQL, verwenden, um ein 
Modell der Anwendung zu bilden. In einem anderen unten beschrie- 
benen Beispiel konnten grafische Schnittstellenmodule fur den 
Benutzer vorgesehen sein, um die Inf ormationen einzugeben. 

Die Regelsprache 6 ist eine hohere Sprache, die es dem Benutzer 
ermoglicht, die Logik eines Programms festzulegen, unabhangig 
von den Hardwarevorrichtungen, die von dem System verwendet 
werden. Die in der Regelsprache 6 geschriebenen Programmodule 
werden von dem Codeerzeuger 24 in einen Computercode ubersetzt, 
der fiir die Ausfuhrung in eirier Umgeburig geeignet ist, in der 
die Module laufen sollen. Die Regelsprache wird unten vollstan- 
diger beschrieben werden. 

Der Kommunikationsmanager 8 fuhrt den Lauf zeit-Ubertrag von 
Inf oarmationen zwischen den Hardwareumgebungen durch, Zum Bei- 
spiel wurde der Kommunikationsmanager 8 Router und Protokolle 
verwenden, um den Datenubertrag zwischen einem Mainframe, einem 
Minicomputer und PC-Arbeitsplatzen zu handhaben. 

Die Testeinrichtung 10, die ein Regelbetrachtungsmodul aufweist, 
ermoglicht es den Prograramiereim, den Programmcode durchzugehen 
und zu entstoren. Das Regelbetrachtungsmodul kann Testdaten 
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erzeugen und eine Regressions- und Beanspruchungstestung einer 
Anwendung ermoglichen . Das Regelbetrachtiingsmodul wird unten 
vollstandiger beschrieben. 

Das PC- Front -End 12 erm6glicht es einer PC-gestutzten Grafik- 
schnittstelle, fur alle CASE-Tool-Funktionen verwendet zu 
werden. Der Regelzeichner 30 ermoglicht es dem Programmierer , 
Progratranodule durch Manipulieren grafischer Darstellungen der 
Regelsprachenanweisungen zu konstruieren . Das PC-Front-End 13 
beseitigt durch Anbieten aller PC-Funktionen in Menus fur die 
Notwendigkeit , daS der Progratnmierer, eine Betriebssystem- 
sprache, beispieisweise DOS, kennt. 

Der Arbeitsplatzmanager 14 hilft beim Managen der Benutzer- 
schnittstelle in einer PC-Umgebung . Das Fensterzeichnermodul 16 
ist ein Tool, das dem Entwickler hilft, Benutzerschnittstellen- 
bildschirme fur Anwendungen zu erzeugen. Die Arbeitsplatz- 
umwandlung 9 managt die Anzeige und Validierung von Bildschirm- 
inf ormationen. 

Das Arbeitsplatzmanagermodul 14 arbeitet in Kotnbination mit 
kotnmerzialisierten Programmen, urn eine Benutzerschhittstelle 
vorzusehen, so wie beispieisweise Microsoft windows. Alle 
Kon^lexitaten der Verwendung eines kommerziellen Enwurf stools, 
wie Microsoft Windows, werden von dem Arbeitsplatzmanager 14 
gemanagt . 

Beim Planen einer Anwendung oder Teilen davon zur Ausfuhrung auf 
einem "IBM PC" ist es bevorzugt, da6 das Microsoft Cooperation 
Betriebssystem, das unter der Handelsmarke "Microsoft windows" 
verkauft wird, verwendet wird. (Fur Hintergrundinf ormationen 
uber Microsoft windows wird der Leser auf die folgenden 
Microsoft Corpbration-Ver6f f entlichungen verwiesen, welche 
hierrait durch Bezugiiahme inkorporiert werden: "Microsoft Windows 
Programmer's Utility Guide"; "Microsoft Windows Application 
style Guide"; "Microsoft Windows Programmer's Reference"; und 
"Microsoft Windows Quick Reference".) 
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Die Dokumentationseinrichtung 20 erzeugt die gesamte technische 
Dokumentation zu einetn in Entwicklung bef indlichen Progranim. Die 
Dokutnentation umfaSt funktionelle Zerlegungen des Systems und 
hierarchische Listungen der Regelsprachenmodule . 

Der Systemerzeuger 22 umf a6t den Codeerzeuger 12 , den System- 
zusatnmensetzer 28 und den Datenzugangserzeuger 26, Der code- 
erzeuger 24 ubersetzt die Regelsprachenmodule in einen Code in 
einer geeigneten Programmiersprache . Der Systemzusarnmensetzer 2 8 
bringt die verschiedenen einprogratnmierten Prograiranelemente 
zusaxtimen, um ein Anwendungsprograinm auszubilden. Der Daten- 
zugangserzeuger 26 ermoglicht es dem Prograram, auf Daten uber 
die Hardwareumgebungen hinweg zuzugreifen. Die Codeerzeugung und 
Progratranausfuhrung wird unten vollstandiger diskutiert warden. 

Das PC-Front-End 12, der Arbeitsplatzmanager 14 und der Kommuni- 
kationstnanager 18 bilden zusammen ein Set von Entwicklungs- 
werkbankmodulen 34 aus, die es dem Benutzer ermoglichen, Daten- 
und ProzeEmodelle fur eine Anwendung und Regelsprachenmodule zu 
planen und diese zu kombinieren, um ein voll funktionsf ahiges 
AnwendungSpl^ogI:a^ttfft zu kreieren. 

Auf der Entwicklungsplattform bei der oben beschriebenen 
beispielhaf ten Konf iguratlon erfoigt der zugrif f auf aile 
umgebungen uber das PC- Front -End 12. Dort konnen die Entwickler 
unter verwendung der Regelsprache ihre Anwendungen einprogram- 
mieren, und die CASE-Einrichtung wird wie erforderlich 
automat i sen ursprunglichen code fur jede utngebung erzeugen* 

Fur die let z ten Phasen der Entwicklung ist . es jedoch zum 
Kompilieren und Testen der Anwendungen erforderlich, jeweils zu 
einem Front- End -Modul fur die geeignete AusfGhrungsumgebung zu 
schalten . Bezuglich dieser Anwendungsentwicklungsaktivitaten 
wird auf jede Umgebung uber ein umgebungsspezif isches Front -End 
zugegriffen. Die umgebungsspezif ische Aktivitat wird unten 
vollstandiger beschrieben werden. 
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Das Sof twareverteilsystem 32 automat isiert und steuert die 
Verschiebung einer Anwendung, Das System managt die Freigabe von 
Software an Zielcotnputer . Das Sof twareverteilsystem 32 lost das 
Problem der Synchronisierung der Verteilung von Software, die z. 

B . auf Hunderten von Personal Compute rn angeordnet ist • Fiir eine 
detailliertere Beschreibung eines Sof twareverteilsystems siehe 

die Internationale Anmeldung fir. PCT/US90/ , iberschrieben 

"Software Distribution System" und am selben Tag wie diese 
Anmeldung eingereicht im Namen von Norman Chin et al.,. die 
hiermit ausdriicklich durcli Bezugnahme inkorporiert wird. 

C. Element e - Bez i ehungen - Mode 1 Ibi Idunq 

1.) BieipentQ upd Pesi^nwgQq 

Bin Merkmal der CASE-Einriclxtung der vorliegenden Erfindung ist 
das Systiememodell . Zum Planen einer Anwendung unter Verwendung 
der CASE-Einrichtung muS ein Entwickler die Anwendung in spezi- 
fische logische Telle zerlegen und diese zu einem Prograrara 
zusammensetzen. Die Daten, die von einem Programm verwendet 
werden, sind in dem Endlager 4, Fig. 2, gemaS einem Eletnente- 
Beziehungen-Modell der vorliegenden Erfindung gespeichert . Die 
verschiedenen Telle einer Anwendung werden als Elemente ausge- 
druckt und durch Beziehungen verknupft. 

Allgemein def iniert ist ein Element irgehdetwas Reales Oder 
Abstraktes, uber das Inf ormationen auf gezeichnet sind. Die 
Inf ormationen sind in einem Set von als Attribute bekannte 
Eigenschaften organisiert, Zum Beispiel konnten die uber 
Beschaf tigte einer Firma gesaramelten Informationen in einem 
Element angeordnet sein, das "BeschSf tigter" bezeichnet wird. 
Die Attribute fur dieses Element konnten sein: Name, Sozial- 
versicherungsnuramer, Wolmadresse, Alter, Geburtstag, Abteilung 
usw. . Ein Element, das "Organisation" genannt wird, wurde solche 
Attribute wie Organisationsname, Adresse, Art der Organisation 

(wie beispielsweise Partnerschaf t Oder Gesellschaf t) usw, 
umfassen. Diese Daten werden in einer Datei in dem Endlager 4 

(siehe Fig, 2) gespeichert. 



* • 



15 

Eine yerbindung zwischen Elementen ist als Beziehung bekannt- 
Zum Beispiel ist in Fig. 3 das Element Organisation 64 jetzt mit 
detn Element Beschaf tigter 58 uber die Beziehung "Beschaf tigt" €€ 
verknupft. Beziehungen werden ebenfalls durch Attribute 
definiert. 

2.) Funktionelle Planuna 

Die funktionelle Planungsphase beginnt mit der Aufgabe der 
Modellbildung, wobei zwei Aufgaben auszufuhren sind: Daten- 
modellbildung und prozesmcdellbildung. 

Die Datenmodellbildung ist das Verfahren zum Erzeugen eines 
Elemente-Beziehungen-Modells fur die echten Daten, die von einem 
Anwendungsprograram zu verwenden sind. Das Verfahren schlie&t die 
Identif izierung eines Elements, wie beispielsweise einer 
"Gesellschaf t" , und die Zerlegung des Elements in Unterelemente 
und Attribute ein. In Fig. 4 ist das Beispielselement, die 
Gesellschaf t 70, in Unterelemente zerlegt: Produkt 72, Personal 
74 und Kunde 76. "Kunde" besteht auS den Attributen Name 78, 
Adresse 80 und dem Element Auftrag 82. Das Element Auftrag 82 
ist zusammengesetzt aus den Attributen: Nummer 84, Datum 86 und 
Status 88.. 

Nachdem der Programmierer einmai ein Modell der Elemente der 
echten Daten gebildet hat, verknupft er . Oder sie die Elemente 
unter Verwendung der Beziehungen, wie beispielsweise der 
Beziehung BeSchaftigt 3, die in Fig. 3 illuStriert ist. 

Im Modellformat werden die Daten in dem Endlager 4 (siehe Fig. 
2) gesp^ichert. unt^r verwendung der Eiemente-Beziehungen- 
Modelliertechnik konnen Daten fur jegliche Anwendungen 
gespeichert und bei nachf olgenden Anwendungen schnell wieder- 
verwendet werden. 

Die ProzeSmodellbildung ist das Verfahren des Aufbaus eines 
Modeils eines Anwendungsprogratnms unter verwendung eines 
Elemente-Beziehungen-Modells. Die CASE-Einrichtung der vorlie- 
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genden Erfindung erfordert, dafi alle Anwendungen zuerst auf ein 
Elemente-Beziehungen-Modell reduziert werden, bevor eine Logik 
des Progratnms festgelegt wird. Das Elemente-Beziehungen-Modell 
ist nicht das tatsachliche Programm. Es ist von den Prbgratnm- 
tnodulen getrennt/ die in der Regelsprache geschrieben sind. Die 
CASE-Einrichtung verwendet jedoch das Elemente-Beziehungen- 
Modell , um die verschiedenen Programmodule miteinander zu 
verkniipfen sowie um das Programm aufz\ibauen und uber das 
Multiprozessorsystem zu verteilen. Elemerite speichern Informa- 
tionen uber den FluS eines Programms, uber die verwendeten 
Datenstrukturen, uber die Benutzerschnitts telle, uber die von 
den Modulen verwendeten Umgebungen und uber die Multiprocessing- 
anf orderuiigen des PrograntmS . 

Zusatzlich stellt das Elemente-Beziehungen-Modell eine Wieder- 
gabe der h6heren Planung des programms aus den Elementen berelt . 
Die CASE-Eiririchtung kann eine technische Dokumentation aus dem 
prozeSmodell herseellen. par eine gegebene Anwendung gibt das 
Elemente-Beziehungen-Modell implizit eine Zusammenf assung einer 
Karte der hdheren struktur und einer detaillierte Beschreibung 
der Logik und der Datenanf orderungen wieder, die notwendig sind, 
um das prograrmn laufen zu las sen. 

Das prozefimodellierende Verfahren erlaubt es Benutzern der CASE- 
Einrichtung, die Ef f izienz durch wiederverwendung von Programm- 
elementen zu maximieren. Das aus dem Elemente-Beziehungen-Modell 
resultierende Programm ist hoch modular. Weil alle Programme, 
die mit der von dieser Erfindung bereitgestellten CASE-Einrich- 
tung entwickelt wurden, dieselben Elementtypen und Beziehungen 
verwenden, ist es wahrscheinlich, daS viele der Programmelemente 
wiedearvearw^ndet werdeii konneA. 

D. Anwendungsmodellelemente und -beziehunaen 

Als Beispiel der vorliegenden Erfindung werden programme, die 
unter Verwendung der CASE-Einrichtung aufgebaut wurden, in 10 
Elementtypen und ii Beziehungen zerlegt, wie in den Fig- 5 und 
6 dargestellt ist. Fur jedes Element und jede Beziehung, die 
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eine Anwendung definieren, wird eine Liste von Attributen und 
Informationen gefuhrt. 

1.) gl^mente 

Das Element Funktion 90, Fig. 5, ist eine AUflistung aller 
Anwendungsprogratnme , die sicli aktuell auf detn System befinden. 
Eine Funktion 90 ist definiert durch die folgenden Attribute: 
Funktionsname, Testbeschreibung und Anwendungsidentif ikation. 

Ein ProzeS 92, Fig. 5, ist eine logische Unterteilung einer 
Funktion 90. Eine Funktion 90 wird typischerweise in zwei Oder 
mehr Prozesse 92 zerlegt. Die Prozesse 92 konnen in Prozesse 92 
niedrigeren Niveaus (Unterprozesse) zerlegt werden. Wenn ein 
Prozefi 92 auf einen anderen ProzeS 92 bezogen ist, ist die 
Beziehung iiraner hierarchisch, Es gibt drei ProzeStypen: Wurzel, 
Blatt und Knoten. Solche Beziehungen definieren die Zerlegung 
eines Unter systems in andere. Das Element ProzeE 92 ist defi- 
niert durch die Attribute: ProzeEname, Beschreibung, Menu- 
beschreibung, Unterprozefimenutyp urid Sequeiiznuntmer . 

Beira Laufenlassen lauft ein Prozefi 92 entweder als Vordergrund- 
oder als HintergrundprozeS . Ein vordergrundprossefi ist ein 
ProzeB, der interaktive Kommunikation mit dem Endbenutzer 
ausftUirt. zum Beispiel kann ein vordergr\indpro2eS grafische 
Funktionen aufweisen, die in einer PC-Arbeitsplatzumgebung 3, 
Fig. 1, befindlich sind. Dies ist der typische On-line- 
/EchtzeitprozeS. Zusatzlich konnen die Vordergrundprozesse 
synchron mit Modulen in anderen Umgebungen kommunizieren, und 
sie konnen asynchron niclit abgerufene Daten enrpfangen. 

Ein HintergrundprozeS wird, nachdem er einmal gestartet ist, 
seine Eingabe verarbeiten, dann stoppen odeir auf w^it^re Eingabe 
wart en. Dies kann ein scliiobweiser ProzeS sein, der beispiels- 
weise auf dem Mainframe lauft und der eine Eingabe aus einer 
Datei erhalt, oder es kann ein kontinuierlicher ProzeS sein, der 
on-line lauft, beispielsweise weil er aus einer warteschiange 
liest. 
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Regeln sind die verf ahrensbeschreibungen der Logik eines Prozes- 
ses. Diese Logik ist in einer die Regelsprache genannten hSheren 
Sprache festgelegt. Die Regelsprache basiert auf den Prinzipien 
der strukturierten Planung und Prograratiierung. Die Syntax der 
Sprache stellt zusatnmen mit den Beschrankungen, die in die 
Architektur eingebaut sind, einen hochmodularen und prSzisen 
SystembeschreibungsprozeS sicher. Die Regelsprache wird unten itn 
Detail beschrieben. 

Unter Verwendung der Regelspracheanweisungen erzeugt die CASE- 
Einrichtung einen Quellcode fur die verschiedenen Utngebungen. 
Die CASE-Einrichtung der vorliegenden Erfindung erzeugt alle 
Codes, die notwendig sind, urn intersystemkotnmunikation (z. B. 
wenn eine Regel . in einer Utngebung eine Regel in einer anderen 
auf ruf t) , interprozeBkotnmunikation (z. B. zwischen verschiedenen 
Prozessen oder Regionen auf derselben Maschine) , Progratran-zu- 
Programra-Verknupfung und eine Benutzerschnitts telle zu 
betreiben. 

Bei dem Elemente-Beziehungen-Modell werden nur Inf ortnationen 
iiber die Regel in einem Regelelement 94 gespeichert nicht die 
Regelspracheanweisungen. Das Regelelement 94, Fig. 5, Fig. 6, 
wird durch seine Attribute definiert: Regelname, Regelbeschrei- 
bung, Ausfuhrungsumgebung und Art der Ausfuhrung (beispielsweise 
synchroil 6d63f asyndhron) • 

Wie bei den Prozessen gibt es drei Kategorien von Regeln: 
wurzel-, Grenz- und Knotenregeln. Eine wurzelifegel wird von 
einem ProzeS 92 aufgerufen. Wurzelregeln haben keine Benutzer- 
Eingabe/Ausgabe-Mdgiichkeit- Eine Knotenregel ist jede Regel, 
die keine Wurzel- oder Grenzregel ist. 

Grenzregeln liegen im Randbereich einer neuen Cotnputerumgebung . 
Diese Regain sind in eine spezielle Kategorie eingruppiert, well 
der Kotnmunikationsmanager 8, Fig. 2, alle Grenzregeln ausfuhren 
muB und weil ihre Eingabe/Ausgabedaten zur Anpassung an weehsel 
in der Uragebung konvertiert werden niussen. 
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Die Regel-Beziehungen werden unter Verwendung von Regelelementen 
94 und den Verwendet-Beziehungen 108 modelliert . 

Koinponenten sind Module von Code, der in irgendeiner dem CASE- 
ExitwicklungssyStetft bekannten ProgratMiiersprache der dritten 
Generation geschrieben ist, wie beispielsweise in C, PL/i oder 
COBOL- Koraponenten werden verwendet, urn Funktionen auszufuhren, 
die nicht von der Regelsprache gehandliabt werden, wie beispiels- 
weise Berechnungen, Datenbankzugrif f xind Anrufe des Betriebs- 
systems. Die CASE-Einrichtung niiraat eiiie "Black Box" -Struktur 
fur die Komponenten an. Eine Black Box hat feste Eingaben und 
Ausgaben. 1st eine bestiirante Eingabe gegeben, erfolgt iramer eine 
vorbestiramte Ausgabe. Dieselbe Analogie trifft auf die Korapo- 
nenten zu. Die Koraponenten haben explizit festgelegte Eingaben 
\ind Ausgaben. 

Das Komponentenelement 36, Fig. 5, Fig. G, enthalt itn Unter- 
scbied zu dem oben bescnriebenen KOitipe>nent$nmodul die f oigenden 
Attribute ; Komponentenname ; Komponentenbeschreibung ; Sprachen- 
name (programmiersprache) , In der der Quellcode der KottqE>onente 
geschrieben ist) ; und Ausf uhrungsumgebung. 

Fenster definieren die Benutzerschnittstelle. Sie legen fest, 
welche Daten von einem Benutzer zu aR2eptieren sind, wie sie 
anzuzeigen sind und wie sie zu akzeptieren sind. Das Fenster- 
eiemene 98 wird verwendee, \m alie infortnationen uber die 
Benutzerschnittstelle zu speichern. Die Fensterinf ormationen 
werden von dem codeerzeugungsmodul 24, Fig. 2, und dem 
Arbeitsplatzumwandlungsmodul 18, Fig. 2, verwendet. 

Ein Fensterelement 98, Fig. 5, weist bei dem Elemente- 
Beziehungen-Modell die folgenden Attribute auf: Fengtemame, 
Beschreibung. Der Fenstername enthalt den Namen einer Masken- 
datei, die ebenfalis in dem Endlager gespeichert ist und die 
Informatiohen enthalt, welche notwendig sind, um eine grafische 
schnittstelle unter verwendung eines grafisehen schnittetellen- 
progranims, wie Microsoft Windows, herzustellen. 



20 

Das View-Element 100, Fig. 5, Fig. 6, ist ein nutzlicher 
Gruppiermechanismus fur das Speichern von Datentypvariablen, die 
von der Regelsprache verwendet warden. Der View 100 ist ein 
hierarchischer Set von benamten Skalaren oder Aggregatwerten . 

Die Views 100 werden innerhalb eines typischen Systems auf drei 
verschiedene Weisen benutzt. Ein Datei-View lOOA gibt einen 
Speicher der Datenkonstrukte wieder, die in einer Datendatei 
gesictiert sind. Die Datenkonstrukte/ die verwendet werden, urn 
die Eingabe und Ausgabe fur die Regeln und Komponenten zu 
beschreiben, sind modulare Views 100. Die Datenstrukturen, die 
verwendet werden, urn die Benutzerschnittstelle zu handhaben, 
werden als Fenstef-views 100 bezeichnet. 

Feldelemente 102, Fig. 5, Fig. 6, sind die Grunddateneletnente, 
die die in einetn Programm verwendeten Variablen auf weisen. Das 
Feldelement 102 speichert alle Inf ormationen uber Datenelemente, 
unabhangig von der Umgebung, in der das Datenelement verwendet 
wird. Die Attribute dieses Elements bestimmen das Format, 
Editierfestlegungen, Bericht- und Bildschirmuberschrif ten und 
andere generische Inf ormationen uber ein bestimmtes Diaten- 
element . 

Ein set 116, Fig. G, ist wie ein view 100, Fig. 5, Fig. 6, ein 
nutzlicher Gruppiermechanismus , der verwendet wird, urn 
zueinander in Beziehung stehende Literale oder Konstanten zu 
speichern. Wertelemente 118, Fig. 6, sind symbolische Wieder- 
gaben von Literalen oder Konstanten. Wertelemente 118 nehmen 
durch symbolische oder englische Namen Bezug auf spezif ische 
Datenwerte oder stellen die Moglichkeit hierzu bereit. Dies 
beseitigt die Notwendigkeit , bestimmte Literalwerte in den 
Regeln fest zu programmieren . 

Die Daten werden in Dateien gespeichert. In einem Elemente- 
Beziehungen-Modell werden Datendateien betref f ende Inf ormationen 
in einem Dateielement 12 0, Fig. 6, gespeichert. 
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2 . ) Ptf^ 7. \ Rhunaen 

Die zehn ein Prograitmi wiedergebenden Elemente sind durch eine 
von elf Beziehungen miteinander verknupft. 

Die L6st-auf-Beziehung 104, Fig. 5, beschreibt die Zerlegung von 
Funktionen 90 zu Prozessen 92. Ihre Attribute sind: Funktions- 
name (erster Teilnehmer) ; ProzeSname (zweiter Teilnehmer) ; und 
Sequenznuituner (fur eine Menuanzeige) . Die Prozesse losen sich 
ebenso in weitere Unterprozesse auf . 

Die Definiert-Beziehung 106, Fig. 5, wird verwendet, urn die 
Beziehung zwischen einem abstrakten ProzeS 92 und den Regel- 
elementen 94 zu beschreiben. Ihre Attribute sind: ProzeSname und 
Regelname. Prozesse konnen auch von anderen Prozessen abhangen. 

Die Verwendet-Beziehung 108, Fig. 5, wird verwendet, urn die 
Verknupfung zwischen einem ausfuhrbaren Modul und einem anderen 
zu beschreiben (beispielsweise Regel verwendet Regel, Regel 
verwendet Komppnente und Komponente verwendet Komponente) - Die 
Attribute einer Verwendet -Beziehiing sind: Modulname und Unter- 
modulname . 

Die Wandelt-um-Beziehung 110, Fig. 5, beschreibt die Verknupfung 
zwischen einem Modul und einem Fens t ere lement . Die Attribute der 
Wandelt-um-Beziehung 110 sind: Regelname (erster Teilnehmer) und 
Fenstemame (zweiter Teilnehmer) . Die Funktion der Wandelt-um- 
Beziehung wird unten vollstandiger beschrieben werden. ^ 

Die Besitzt-Beziehung 112, Fig. 5/ verbindet Elemente mit den 
View-Elementen ICQ, die ihre logischen Datenschnittstellen 
beschreiben. Das Regelelement 94, das Komponentenelement 96, das 
Fensterelement 98 und das Dateielement 120, Fig. 6, konnen View- 
Elemente 100 besitzen. Die Attribute der Besitzt-Beziehung sind: 
Regel -/Konponente-/ Fens ter- bzw. Dateiname; Element typ (entweder 
Regel/Kbmponente/Fenster Oder Datei) ; view^Name xrnd view-verwen- 
dung (entweder In, Out Oder Inout fur eine Benutzerschnitt- 
stellen-Eingabe/Ausgabe) . 
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Die SchlieSt-ein-Beziehung 114, Fig. 5, verbindet Datengrofien 
miteinander, um Struktureri auszubilden, view- Element e k6nneii 
Unter-Views 100 und Felder 102 umfassen. Die Attribute der 
Schlie6t-ein-Bezieh\ing 114 sind: View-Name (erster Teilnehmer, 
View hoherer Ordnung) ; view-/Feld-Name (zweiter Teilnehmer) ; 
Elementtyp (Elementtyp des zweiten Teilnehmers: entweder View 
Oder Feld) ; Sequenznummer (verwendet, um Unter-Views und -Felder 
zu ordnen) ; Auf trittshauf igkeit (wird verwendet, um Arrays in 
Strukturen zu erzeugen. 

Die Besitzt-Set-Bezieh\zng 124, Fig. 6, verkniipft ausfuhrbare 
Module mit den Literal-Set -Werten, auf die sie sicli beziehen. 
Eine Regel kann einen Set durch eine lokale Erklarung unter 
Verwendung der Regelsprachen-DCL-Anweisiing besitzen, wie unten 
diskutiert wird. Die Literalwerte werden dann automatisch in das 
Regelmodul eingeschlossen, wenn der Code generiert wird. Ein 
Komponentenelement 96 kann ebenfalls Sets besitzen. Die 
Attribute der Besitzt-Set-Beziehung 124 sind: Modulname; 
Modulelementtyp (beispielsweise Regel oder Komponente) ; Setname. 

Die Enthalt-Beziehung 126, Fig. 6, verknupft literale Daten- 
groSen mit einem gemeinsamen Setelement 116. Ein Setelement 116 
enthait 2. B. 18 Mitglieder-Werte in dem Wertelement 118. pie 
Attribute fur die Enthalt-Beziehung 126 sind: Setname; Wert; 
Symbolname; Sequenznummer. 

Letztlich weist das CASE-System Dateibeziehungen auf: ein 
Dateielement 12 0, Fig. 6, wird eingegeben 132 von einem Feld- 
element 122; das Dateielement 120 liefert auch Inf oimationen an 
eine andere Datei 120; und ein Datei -View-Element 105 beschreibt 
12 8 ein Dateielement 120. 

E. PT-nzegmo dellbildunorsreduktionstechnik 

Alle Anwendungen, die mit der CASE-Einrichtung entwickislt 
wurden, konnen auf einen Set von vorgewahlten Elementen und 
Beziehungen reduziert werden, wie beispielsweise die oben 
beschriebenen Elemente und Beziehungen. Das Verfahren beginnt 
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mit dem Definieren der Funktionselemente 90, Fig, 5. Eine 
Funktion ist jedetn Anwendvmgsprogramm zur Durchfuhrung einer 
Aufgabe oder Funktion aquivalent . Das Funktionselement 1 enthalt 
eine generalisierte Beschreibung der Anwendung. Eine Funktion 
wird in Prozesse zerlegt. Die Prozesse geben allgemeine F\inktio- 
nen wieder, die das Programm ausfuhren muB. 

Zum Beispiel konnte ein ProzeEelement 92 in einer Anwendung zur 
Durchfuhrung eines Borsenhandels uberschrieben sein "Termin- 
handel-Eingang" . Ein ProzeSelement 92, Fig. 5, speichert 
Informationen, die den Prozefi beschreiben. Prozesse konnen in 
weitere Prozesse zerlegt werden^ Bei jeder Zerlegung wird die 
Information uber die neuen Prozesse in einem ProzeSelement 92 
ge speichert. 

Das Funktionselement 90 und die Pro zeSel entente 92 erzeugen einen 
hoheren Uberblick uber eine Anwendung. Wahrend der Modell- 
bildungsphase stellt die CASE-Einrichtung, die von dieser Erf in- 
dung verges tellt wird. Tools zur Unterstutzung der Entwicklung 
zur Verfugung. Der Programmierer kann von der CASE bereit- 
gestellte Grafiken verwenden, urn das ProzeiSelement 92, das 
Funktionselement 90 und die Lost-auf -Beziehungen 104 festzu- 
legen. Der Verwender sieht die Funktionen und Prozesse gelistet 
in Menus. Die CASE-Einrichtung unterstutzt ebenso den Analy- 
sierer und Verwender bei der prozeiSmodellbildung, indem sie 
erlaubt, dafi diese Funktions-/ProzeSzerlegung beispielsweise von 
einem Analysieirer und einem Programmierer in Form von Prototypen 
interaktiv ausprobiert werden kann. Der Analysierer kann seine 
Gedanken eingeben. Menus erzeugen, die die Eingabe wiedergeben, 
und Eingaben (Andemingen) von dem Programmierer fordem, falls 
diese tatsachlich der Weg sind, auf dem sich der Benutzer 
vorstellt, daS ein Problem gelost werden soil. 

Nachdem einmal ein Anwendungsproblem auf eine Reihe von Funk- 
tionselementen 90 und ProzeSelementen 92 reduziert worden ist, 
beginnt die technische Planung. Bei der technischen Planung 
werden die Programmcodef estlegungen durch das Regelelement 94, 
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das Komponentenelement 96 und das Fens ter element 98 beschrieben. 



Der wichtige Aspekt der technischen Planung ist die Festlegung 
der Regain, Komponenten, Fenster und views, die notwendig sind, 
um das Programm laufen zu lassen. Fig. 7 ist ein Beispiel eines 
ProzeBf luSdiagramms , das Elemente-Beziehungen-Modellbildungs- 
Standards verwendet. Die eckigen Kasten 134, 136, 138, 140, 142, 
144 in der Figur stehen fur Prozel^- und Funktionselemente . Die 
Kapsel-formigen Kasten 148-182 stehen fur Regeln. Die ovalen 
Kasten 184, 18 6, 192, 194, 196 stehen fur Komponenten. Die 
Kreise 188, 190 stehen fur Fenster. Das ProzieSf luSdiagramm wird 
verwendet, um die Information, die in den Regelelementen 94, den 
Komponentenelement en 96, den Fensterelementen 98 und den View- 
Elementen 100 (siehe Fig. 5) enthalten ist, sowie die Beziehun- 
gen zwischen ihnen festzulegen. 

Bezugnehmend jetzt auf Fig. 2 sind dort Entwicklungswerkbank- 
module 34 gezeigt, die zur Erzeugung des Elemente-Beziehungen- 
Modells und des Regelsprachencodes verwendet werden . Fig. 2A 
zeigt eine beispielhaf te Umsetzung der Module 34 in einem 
dreifach unterteilten System, wobei die Bntwicklungswerkbank- 
module 34 in der PC-Umgebung 3 vorhanden sind. .Die Entwick- 
lungswerkbankmodule 34 weisen eine Reihe von graf ikgestutzten 
Tools auf, die einem Benutzer helfen, eine Anwendung zu planen 
und umzusetzen, indem sie einen vorgewfihlten Set von Elementen 
und Beziehungen und eine Regelprogrammiersprache bereitstellen. 
Alles, was ein Benutzer unter Verwendung der Entwicklungs- 
werkbankmodule 34 plant, wird in einem lokalen Endlager 60 in 
der PC-Umgebung 3 gespeichert werden. Gegebenenf alls werden die 
Daten in dem lokalen Endlager 60 verwendet, um das zentrale 
Endlager 4 zu besetzen, das sich in der Mainf rame-Umgebung 1 
befindet. Alles, was Dokumentation oder Umsetzung eines Systems 
ausmacht, muS wahrend des Entwicklungszyklus gegenuber dem 
zentralen Endlager 4 definiert sein. Letztlich wird die 
Anwendxing von dem zentralen Endlager 4 beispielsweise an End- 
Benutzer-PC-Arbeitsplatzumgebungen (und andere Umgebungen falls 
erforderlich) verteilt. 
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Die Verwendung der Entwicklungswerkbankmodule 34 muB jedoch 
nicht zu jeder Zeit an das zentrale Endlager 4 angeschlossen 
sein. Aus Grunden der Ausfuhrung ist es vorteilhaft zu vermei- 
den, bei detn zentralen Endlager 4 standig nach Inf ormationen 
anzufrageri. Das Herauf laden von und Herunter laden zu dem 
zentralen Endlager erfolgt uber den Kotnmunikationsmanager 8, der 
auf das lokale Endlager 60 zugreift. 

Das lokale Endlager 6 0 ist eine Speicliervorrichtung, die in der 
PC-Umgebung 3 angeordnet ist . Ein Datenbanktreibermodul 54 weist 
Software zum Speichem von Inf ormationen und zum Zugreifen 
darauf auf. Ein Treiber 52 fur das lokale Endlager ermoglicht 
detn Benutzer Zugriff auf die Entwicklungswerkbanlanodule 34 und 
ermoglicht dem Entwicklungswerkbankmodul 34, auf das lokale 
Endlager 60 uber das Datenbanktreibermodul 54 zuzugreifen. 

Ein Hierarchie-Diagramm-Modul 38 ist in dem Entwicklungswerk- 
banfcmodul 34 vorgesetien, um es einem Benutzer zu ermoglichen, 
die Dateii- und ProzeSmodule festzulegen, die das logische 
Fundament des Anwendungsprogramms bereitstellen- Das Hierarchie- 
Diagraram-Modul 38 konnte z. B. ein Elemente-Beziehungen- 
Diagramm, das zur Datenmodellbildung verwendet werden konnte 
beispielsweise zum Festlegen des Elemente-Beziehungen-Modells 
fiir die echten Daten, die von dem Anwendungsprogramm verwendet 
werden. Mit dem Elemente-Beziehungen-Diagraram kann ein Benutzer 
grafisch Elemente festlegen und die Elemente in Unterelemente 
und definierende Attribute zerlegen. Zum Beispiel wurde in Fig. 
4 eine Gesellschaft 70 in Unterelemente Produkt 72, Personal 74 
und Kunde 76 zerlegt . Das Elemente-Beziehungen-Diagramm stellt 
Module zum grafischen Festlegen solcher Elemente und Beziehungen 
bereit . 

Die Entwicklungswerkbanlcmodule 34 konnten auch ein Matrixaufbau- 
modul 42 aufweisen, das es einem Benutzer ermoglicht, Abbildun- 
gen zwischen verschiedenen Arten von Elementen in Matrizenform 
zu speichem. Die Matrizenabbildungen werden typischerweise in 
der strategischen Planungsphase der Analyse verwendet, um die 
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Beziehungen zwischen dem Daten- und ProzeSfluS f estzuhalteri. 
Auch die erzeugte Matrix wird in dem lokalen Endlager 6 0 und dem 
zentralen Endlager 4 gesichert. 

Das Fensterzeichnermodul 16 erraoglicht es einem Benutzer, Masken 
zu erzeugen, die die Sclmittstelle sind, uber die der End- 
beriutzer einer Anwendung kommuniziert . Die Masken des Fenster- 
zeichnermoduls 16 bestimmen das "Aussehen" und das von einer 
Anwendung vermittelte "Gefuhl". 

Unter Verwendung des Fensterzeichnermoduls 16 kann der Verwender 
entweder eine neue Fensterdatei fur das zugehorige Fenster- 
element erzeugen oder eine zuvor erzeugte Fensterdatei, die in 
dem Endlager 4 gespeichert war, modif izieren. 

Unter Verwendung des Beispiels eines PC, der mit einem Microsoft 
Windows Betriebssystem arbeitet, stellt das Fensterzeichnermodul 
16 die Software zur verfugung, die fur einen Benutzer notwendig 
ist, um in dieser Umgebung eine grafische Sclmittstelle zu 
erzeugen. 

Zum Beispiel konnte ein Benutzer auf das Fensterzeichnermodul l^ 
von der Entwicklurigswerkbank aus zugreifen, wobei ein leeres 
Fenster erscheinen wurde, Der Benutzer konnte dann eine Liste 
von Fensterdateien auswShlen, die zuvor in dem lokalen Endlager 
60 definiert wurden. Das Anklicken eines dieser Fenstemamen 
bringt eine Tafel hervor, auf der man die Ob j ekte " zeichnen" 
kann, die dem Endbenutzer der Benutzeranwendung prasentiert 
werden . 

Zusatzlich zu dem Maskenschirm gibt es vornehmlich zwei Arten 
von Objekten, die zu manipiilieren sind: Elementobjekte und 
lokale Ob j ekte. 

Elementobjekte sind Feldelemente 102 und View-Elemente 100, die 
definiert worden sind und sich in dem lokalen Endlager 60 
befinden. Ein Views-Menu kann eine Liste der View-Elemente 100 
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bereitstellen, die an einem Fenster anhangen, das ein Benutzer 
zeichnet, gefolgt von den auswahlbaren Feldeletnenten 102 und 
mehrfach auftretenden Unter-views, die wiederum an diese ange- 
hangt sind, Ein Benutzer kann jedes dieser verfugbaren Objekte 
auswahlen, sie auf der Maske anordnen und sie individualisieren. 

Felder konnten als leere geklainraerte Kasten erscheinen mit einer 
Bildschinnbezeichnung auf der linken Seite. Der Wert des Felds 
(falls vorhanden) erscheint zur Laufzeit zwischen den Klatnmem. 
Die Bildschinnbezeichnung wurde definiert, als das Element 
erzeugt wurde, und ist dem Feld in dem Endlager 4 zugeordnet. 
Ein Benutzer kann die Bildschinnbezeichnung als Textobjekt auf 
der Maske editieren. Falls das Bi Ids chirmbezeichnungs feld Oder 
das Feldelement leer ist, wird stattdessen der Feld)curzname 
verwendet . 

Diese Objekte konnen durch Anklicken der Objekte und Gedruckt- 
halten der Maustaste, wahrend das Objekt zu dem gewunschten Ort 
gezogen wird, uber die Maske bewegt werden. 

Lokale Objekte sind der Maske zugeordnet, aber nicht gegenuber 
dem lokalen Endlager 60 definiert. Der Benutzer kauin lokale. 
Objekte von einem Objektmenu auswahlen. 

Es gibt drei Arten von lokalen Objekten: 

Steuerobjekte, die vom Endbenutzer mit einer Maus ausgewahlt 
werden koxmen. Steuerobjekte, die Druckknopfe, Druckkasten, 
Menubalkengegens t ande und Pul 1 - down - Gegens tande au f we i s en . 
Textobjekte, die auf der Maske als Beschrif tungen oder 
Anweisungsnachrichten angeordnet werden konnen. 

Durch Steuem der Anordnung der Bildschirmobjekte kann ein 
Benutzer ein Fenster aufbauen, das einem View-Element 100 
zugeordnet ist, und diese Fensterf estlegung fiir Routine- 
anwendungen in dem lokalen Endlager 60 und in dem zentralen 
Endlager 4 sichem. Die Fensterdateien, die bei diesem Bei.spiel 
erzeugt werden, werden benutzt, urn die Benutzerschnittstelle 
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eines Anwendungsprograrams zu erzeugen. Die unten vollstandiger 
beschriebene umwandlungsfunktion stellt die Sof twaremodule zum 
Verknupfen der vom Benutzer festgelegten Fensterdatei mit den 
Fenstern bereit, die von den grafischen Schnittstellenroutinen 
bereitgestellt werden: 

Das Regelzeichnermodul 3 0 stellt die Schnittstelle bereit, die 
es Benutzem erlaubt, Regelsprachenmodule zu erzeugen, die den 
Regelelementen 94 zugeordnet sind. Die Regelsprachenmodule und 
Regelelemente sind verknupft. Jedes Regelelement enthSlt 
Informationen betreffend die Funktionalitat der Regel \ind den 
Namen eines entsprechenden Regel sprachenmoduls. Die entsprechen- 
den Regelsprachenmodule enthalten Anweisungen, vim die Funktiona- 
litat des verknupften Regelelement s auszufuhren. Typische 
Anweisungen, die Regelsprache aufweisen, werden unten genauer 
beschrieben. 

Das Berichtzeichnermodul 4 0 wird verwendet, um Formate fur 
Endbenutzerberichte zu entwerfen, in einer Weise, die derjenigen 
des Festlegens von Fenstern fur grafische Schnittstellen unter 
verwendung des Fensterzeichnermoduls 16 ahnlich ist* 

Das Datenbankadministratormodul (DBA) 44 ist eine Koramunika- 
tionseinrichtung, die es einem Benutzer ermpglicht, Daten in dem 
lokalen Endlager 60 auf zuf rischen und Anderungen in das zentrale 
Endlager 4 zu laden. Das DBA-Modul 44 wird auch verwendet, um 
Berichte uber die Inhalte des lokalen Endlagers 60 zu erzeugen. 
Dieses Modul verwendet den Lokalendlagertreiber 52, den 
Datenbanktreiber 54 und das Kommunikationsmanagermodul 8 in der 
PC-Umgebung 3, um auf Daten in dem lokalen Endlager 60 
zuzugreifen und um Daten zum und von dem zentralen Endlager 4 zu 
senden und zu empfangen. Unter Verwendung des DBA-Moduls 44 
konnen Objekte und Attribute aus dem Endlager 4 zur Anderung 
Oder Loschung ausgewahlt werden. Das DBA-Modul 44 weist eine 
Systemsicherheitskonqponente auf, die fordert, da& sich Benutzer 
bei der Mainframe -Umgebung . 1 anmelden und daE nur bestimmte 
Klassen von Benutzern die Erlaubnis zum Loschen bestimmter 
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Objekte haben konnen. Die Auf f rischxingsmoglichkeit erlaubt 
Benutzem, Objekte aus dem Endlager 4 heraus zu laden. 

Die Entwicklungswerkbankmodule 34 ermoglichen es den Benutzem, 
die Datenmodellierung festzulegen, die notwendig ist, urn 
Eletnente und Beziehungen festzulegen, sowie die Regel-, 
Komponenten- , Views-, Feld- und Fenstermasken festzulegen, die 
notwendig sind, um das letztendliche ausfuhrbare Progratnni in den 
spateren Entwicklungsschritten zu erzeugen. Unter Verwendung der 
Entwicklungswerkbankmodule 34 konnen diese logischen Strukturen 
in dem Endlager 4 gespeichert werden. 

F. ATifbaiien des Procrranuns 

Bei fertigem Eletnente -Beziehungen-Modell kann der Progratnmaufbau 
beginnen. Der Quellcode wird aus den Regelsprachentnodulen, den 
Komponenten, Fenstem, Dateien, Feldem, Views, Werten und Sets 
erzeugt, die in dem Endlager gespeichert sind- Die Regeln, 
Komponenten, Fenster und Dateien sind Programmodule, die sich 
von den Regelelementen 94, Komponentenelementen 96, Fenster- 
elementen 98 und Dateielementen 12 0 unter scheiden, die in dem 
Elemente- Beziehungen-Modell (siehe Fig. 5 und 6) verknupft sind* 
Diese Elemente speichem Informationen liber das tatsachliche 
Programmodul, aus dem das Anwendungsprogramm erzeugt wird. 

in dieser Stuf e des Aufbaus wird die meiste Arbeit beim Aufbauen 
des Prograrams getan. Die Datenstrukturen werden durch die View- 
Elemente 100, die Feldelemente 102, die Setelemente 116 und die 
Werteelemente 118 definiert. Die Codeerzeugereinrichtung 24, 
Fig. 2, kopiert diese Elemente in diejenigen Prograrattiodule, die 
mit ihnen uber die Regelelemente 94 und Koti^onentenelemente 96 
(siehe Fig. 5) in Beziehung stehen. Komponentenmodule mussen 
nicht von dem Programmierer aufgebaut werden, da sie zuvor 
programmierte Unterroutinen sind, die von der CASE-Einrichtung 
bereitgestellt. werden, um grundlegende mathematische Operationen 
und Betriebssystemzugrif f e auszufuhren. Die CASE-Einrichtung 
erlaubt es jedoch, daS neue Komponenten aufgebaut und in dem 
Endlager 4, Fig. 2, gespeichert werden. Der ProzeS des Code- 
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erzeugens wird unten vollstandiger beschrieben. 
1. wif^derverwendbarkei tsanalyg^ 

Noch vor der Erzeugung der Regelsprachenmodule, beispielsweise 
unter verwendung des Regelzeichnerraoduls, beschleunigt die CASE- 
Einrichtung die Progratnmentwicklung, weil sie ein Verfahren zur 
Wiederverwendung zuvor erzeugten Codes bereitstellt . Bel der 
Elemente-Beziehungen-Modellbildung kann viel derselben Logik 
einer Anwendung bei anderen Anwendungen wiederveinvendet werden. 
Es ist einfacher. Code wiederzuverwenden, der bereits entwickelt 
und getestet worden ist, als ilm wieder zu erzeugen. Dies 
bedenkend, sollte eine wiederverwendungsanalyse durchgefuhrt 
werden. 

Bei dem in dem Endlager . 4, Fig. 2, gespeicherten Elemente- 
Beziehungen-Modell konnen die Elemente zur Verwendung durch 
andere Elemente abgefragt werden. Zum Beispiel gibt bei einem 
Endlager 4, das in einer von IBM DB2 unterstutzten Datenbank 
existiert, eine Where Used- (Wo benutzt) -Anf rage bezuglich des 
Feldelements 122, Fig. 5, eine biste aller View-Elemente 10 OA 
aus, die das Feldelement 122 verwenden. Die Verwendung der View- 
Elemente kann weiter abgefragt werden um f estzustellen, welche 
Regeln, Komponenten oder Fenster jene View-Elemente verwenden. 
Dieses Verfahren erlaubt es den Prograramierern, zuvor einpro- 
grammierte Regeln und Komponentisn zu erkunden. Eine Find Where - 
(Finde wo) -Abf rage wird alle Elementattribute iiber die gesamte 
Datenbank nach bestimmten Worten oder Zeichenf olgen durchsuchen. 

zusatzlich ermoglicht es die CASE-Einrichtung Programmierem, 
ein Schlusselwort fur alle erzeugten Regeln, Komponenten und 
Felder zu definieren. Ein Suchbefehl kann ausgefuhrt werden, um 
Elemente zu lokalisieren, die ein bestiramtes Schlusselwort 
besitzen. Ein Prograramierer kann kompliziertere Suchen durch- 
fuhren, wie eine solche, um alle Schlusselworter zu finden, die 
beispielsweise mit "CU" anfangen und mit "Pp" enden. 

Nachdem ein Programmierer ein Modul lokalisiert hat> das wieder- 



verwendbar sein kann, kann er oder sie weitere Informationen 
durclx Durchsehen der Beschreibung oder anderer Attribute 
erhalten, die dem Element zugeordnet sind- 

2. nig* Reaelsprache 

Die Regelsprache ist eine hohere Prograrnmiersprache, die jeden 
StandardfluS von Steuerkonstrukten unterstutzt. Was an der 
Regelsprache ungewohnlich ist, ist daS sie kein Mittel zur 
Beschreibung ausgearbeiteter Datenstrukturen erfordert und daB 
sie Datenkonstrukte aufweist, die auf Informationen in den 
Elemente-Beziehungen-Modulen zugreifen. Die Besclireibung aller 
Datenstrtikturen, die von einem Programm innerhalb der CASE- 
Einrichtung verwendet werden, ist in den View- und Set-Elementen 
in dem Elemente-Beziehungen-Modell des Programms gespeichert. 
Alle Regeln, die vori einera Programm verwendet werden, teilen 
sich Datenstrukturen. Das Sich-Teilen von Datenstrukturen sorgt 
fur eine strikte Koordination zwischen den Daten, die von einem 
Regelsprachenmodul auf ein anderes ubertragen werden. Diese 
Technik verhindert eine Hauptquelle von Programmf ehlem eine 
Fehlpassung von Daten, die zwischen Unterroutinen ubertragen 
werden. 

Eine Regel besteht aus keiner oder mehr erkiarenden Anweisungen 
gefolgt von keiner oder mehr ausfuhrbaren Anweisungen. 

Ein erklarter Datentyp raufi einer der folgenden Typen sein: 
Smallint, integer, Char, Varchar, Decimal, Signed Picture oder 
Like (ein bereits erklarter Gegenstand) . Die erklarende Anwei- 
sung hat die Form: 
DCIi 

Erklarung; [Erklarung; ...] 
ENDDCL 

wobei die Erklarung ist: 

Bezeichnung [ (s) ] [, Bezeichnung [ (s) 1, -..] 

erklare Typ oder EXTERNe Bezeichnung [, Bezeichnung, ...] 

SET 
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Die Datentypen werden vollstandiger im T^hang C erklart, der 
hieran angehangt ist . 

Die Regelsprache unterstutzt drei Arten von ausfuhrbaren 

Anweisungen: 1) Zuordnungsanweisungen; 2) externe SteuerfluE- 

anweisungen; und 3) interne Steuerf lufianweisungen: 

Zuordnungs- externe Steuer- , interne Steuer- 

anweisungen f luSanweisungen f luSanweisungen 



MAP USE IF . 

OVERLAY RETURN CASEOF 

CLEAR CONVERSE DO 

ASYNC 

Zuordnungsanweisungen andem die Daten, die in Prograinmvariablen 
enthalten sind und von diesen gehalten werden. Die MAP Anweisung 
ordnet einen bestitranten Wert an einem variablenpunkt an. Die 
OVERLAY- Anweisung ersatz t die Inbalte einer Variablen durch 
einen bestitnmten DatengroSe. Die CLEAR-Anweisung ersetzt ein 
numerisches Feld durch NUll-werten und ein Zeichenfeld durch 
Leer-Zeichen. Die Syntax der zuordnungsanweisungen ist: 

MAP Ausdruck TO Variable 

OVERLAY Datengr6Se TO variedDle 

CLEAR variable 

Vier Anweisungen in der Regelsprache handhaben den externen 
Steuerflufi zwischen Prograitimodulen, Die USE-Anweisung ermoglicht 
es einem Programmodul , eine andere Regel oder Komponente aufzu- 
rufen. Sie ist einer unterroutinen- Call -Anweisung in anderen 
Prograrnmiersprachen ahnlich. Die Syntax ist: 

USE MODULE Komponente 

USE RULE Regel [NEST] 

Die Next-Option zeigt an, daS alle Fenster, die die Regel 
aufrufen, in einen "Auftauch" -Modus gelangen, das heiSt, daS sie 
liber dem zuvor angezeigten Bildschirm angezeigt werden. 



Die RETURN- Anweisung fuhrt die Steuerung zuruck zu der Regel, 
die die USE-Anweisung ausgefuhrt hat: 
RETURN 
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Die CONVERSE-Anweisung stellt eine Kotnraunikation zwischen der 
Regel auf dem PC und der Benutzerschnittstelle bereit . Eine 
typische CONVERSE-Anweisung ist: 

CONVERSE WINDOW Fenster 

Die CONVERSE-Anweisung ruft zur Laufzeit verschiedene Module 
auf, die von der vorliegenden Erfindung bereitgestellt werden, 
urn physikalisch die Umwandlungsbeziehung zwischen Fenster und 
Regel auszufuhren. Bei dem Beispiel einer auf dem PC ansassigen 
Regel, die auf ein Fenster auf dem PC zugreift, werden die 
umwandlungsmodule in der PC-Utagebung 3 ansassig sein und an das 
Betriebssystem dieser Umgebung anlcuppeln, um eine grafische 
Benutzerschnittstelle bereit zustellen . 

Die Funktion der umwandlungsmodule ist es, die gesamten Bild- 
schirmeingaben und -ausgaben fur eine Regel zu managen. Die 
Module senden die Eingaben des Benutzers durch Belegung eines 
bestimmten Felds zu der Regel. Vor dem Ubertragen der Eingaben 
des Endbenutzers zu der Regel, die das Fenster umwandelt, fOhrt 
das umwandlungsmodul eine BditieruberprGfung \ind Validierung 
jedes Eingabefelds durch, das durch die in dem Endlager 
definierten Attribute festgelegt ist. Falls z. B. ein bestimmter 
set von Werten vorlag, der fur ein gegebenes Feld zu einer Regel 
in Beziehung stand (z. B. falls ein Farbfeld nur gleich "rot" 
Oder "blau" sein konnte, ware jede Antwort "grCui" ein Fehler) . 

Beim Erzeugen des Benutzerbildschirms ist es auch eine Funktion 
des umwandlungsmoduls , an das Betriebssystem anzukoppeln, um die 
Benutzerschnittstellenbildschirme, die durch die Fensterdateien 
festgelegt sind, auszugeben. 

Mit der ASYNG-Ahweisung unterstutzt die Regelsprache einen 
asynchronen DatenfluB. Nicht angefragte Daten ermoglichen es zum 
Beispiel in einem System, das einen parallel arbeitenden stratus 
Minicomputer aufweist, einer Regel auf dem Stratus, Daten zu 
einer Regel auf dem PC zu senden. Dies wird unterstutzt unter 
Verwendung der folgenden Anweisungen: 
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ASYNC 



ATTACH 



ASYNC 



DETACH 



ASYNC 



REFRESH 



ASYNC 



ROUTE 



Der ASYNC ATTACH-Bef ehl startet das Empfangen von nicht ange- 
fragten Eingaben, z. B. gesendet von einer Regel auf dem 
Stratus, durch eine Regel auf dem PC. Der ASYNC DETACH-Bef ehl 
fiihrt die exakte Umkehr von ATTACH aus . Er kann nur nach einem 
ATTACH-Bef ehl verwendet werden, wobei zu seinem Zeitpunkt der 
Empfang von nicht angefragten Eingaben iinterbrochen wird. Der 
ASYNC ROUTE-Befehl schaltet eine Datenerneuerung von einer PC- 
Regel zu einer anderen. Die ASYNC REFRESH-Anweisung leitet das 
automatische Aktualisieren eines spezifischen Felds ein, sofem 
die ATTACH-Anweisung verwendet worden ist. 

Die Regel sprache weist drei verschiedene Anweisungen auf, urn den 
SteuerfluS innerhalb einer Regel zu ordnen, 

Eine IF-Anweisung steuert die Ausfuhrung basierend auf einer 

bestitnmten Bedingung: 

IF Bedingung [ausfuhrbare Anweisung . . . ] 
[ELSE [ausfuhrbare Anweisung , ,] ] 



Die CASEOF-Anweisung wahlt einen von mehreren alternativen 
Ausfuhrungswegen basierend auf dem Wert einer variablen. Die 
Syntax ist 

CASEOF Variable 

CASE Konstante [ Konstante . . . ] [ ausfuhrbare Anweisung 

. . .] 

[ CASE Konstante [ Konstante . - . ] [ ausfuhrbare Anweisung 

[ CASE OTHER ] 
ENDCASE 

Eine DO- Anweisung steuert die Ausfuhrung von Wiederholungs- 



ENDIF 
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schleifen. Die Syntax ist 

DO [ FROM DatengroEe ] t TO DatengroSe ] [ BY DatengroSe ] 
[ INDEX Variable ] [ ausf uhrbare Anweisung . . , ] 
[ WHILE Bedingung [ ausf uhrbare Anweisung ... 11 

ENDDO 

Alle DatengroSen und Variablen, die festgelegt werden, urn eine 
DO-Sclileife auszufuhren, mussen ganze Zahlen sein. Die 
Vorbelegungen fvir die DO-Anweisungen sind: FROM =1, TO = n, BY 
= 1, wobei n eine ganze Zahl ist. 

innerhalb der IF- , CASEOF- und DO-Anweisungen treten Bedingungen 
auf. Eine einfaclie Bedingung ist: 

Ausdruck logischer Operator Ausdruck 

Oder Ausdruck INSET Set, 
wobei der logische Operator einer der folgenden ist: 

<> > 
< >= 

Eine Bedingung ist aus einfachen Bedingungen Oder anderen 
Bedingungen auf gebaut : 

einfache Bedingung 

Oder (Bedingung) 

Oder NOT Bedingung 

Oder Bedingung AND Bedingung 

Oder Bedingung OR Bedingung 

Die INSET -Anweisung wird verwendet , um f estzustellen, ob eine 
gegebene Variable oder Konstante als Wert innerhalb eines SET 
auftaucht. Zum Beispiel, gesetzt den Fall X ist ein Datengegen- 
stand, dessen Datentyp koit5>atibel mit dera Datentyp des Set ist, 
dann ist : 

X INSET SET NAME 

eine Bedingung, die entweder TRUE oder FALSE ergibt, abhangig 
davon, Ob mindestens einer der Werte in SET NAME den Wert von x 
trifft. 



Bin Prograiranierer verwendet die Regelsprachenanweisungen^ um die 
Logik des Prograitims auszuschreiben. Fur weitere Inf ormationen 
bezuglich der Regelsprache sollte auf die Anlidnge A bis F, die 
hieran angehangt sind, Bezug genotnmen werden. 

3 . Benutzerschnittstellenf enster 

Die Benutzerschnitt Stella wird fur jede Anwendung unter Verwen- 
dung des Fensterzeichners 16, Fig. 2 der CASE-Einrichtung 
konstruiert . Wie oben beschrieben, ist das Fensterzeichnermodul 
16 das Programm, das vorgesehen ist, um in einem gegebenen 
Betriebssystem Benutzerschnittstellen aufzubauen. In dem 
Beispiel der obigen PC-Umgebung wurde der Regelzeichner an das 
Microsoft Windows-Betriebssystem ankoppeln. Das Fensterzeichner- 
modul 16 wiirde dann die Maus-gestutzte Benutzerschnittstelle 
aufweisen. 

Das Fensterzeiclinermodul 16 wird auch verwendet, um Bildschirm- 
abbildungen von Daten zu erzeugen, die in den Feldelementen 102 
und View-Elementen 10 0 (siehe Fig. 5) bezeictinet sind. Das 
Fensterzeichnermodul 16, Fig. 2, erzeugt eine Datei. Diese Datei 
enthalt Daten zur Erzeugung einer Bildschirmabbildxxng des View- 
Fensters. Nach Erzeugen tind Sichem der Maske erzeugt die CASE- 
Einrichtung der Erfindung auch andere Dateien, wie z. B. eine 
Datei, die den Code fur die. "gezeichnete" Maske enthalt. Eine 
andere Datei k6nnte den Code fur die Menus trukturen enthalten, 
die von einer Maske verwendet werden. 

G. CodeerzeugunQ 

Nachdem ein Modell einer Anwendung gebildet worden ist, und die 
Regain, Komponenten und Fenster erzeugt worden sind, stellt die 
CASE 'Einrichtung einen Quellcode her, 

Zubereitung ist die Codeerzeugungsphase . Wenn eine Anwendung 
zubereitet wird, werden die View-Elemente 100 und die SET- 
Elemente 116, Fig. 5, verwendet, urn Kopierbucher zu erzeugen. 
Ein Kopierbuch ist eine Datei, die in den Quellcode eines 
Programmoduls hineinkopiert wird. Die CASE-Einrichtung erzeugt 



ein Kopierbuch fur jede Datenstruktur und schliefit eine Kopie . 
dieser Datei in jede ausfuhrbare Regel, jedes Fenster bzw. 
Komponente ein, die sich auf einen bestitnititen view oder Set 
beziehen. 

Ziibereitung erzeugt auSerdem einen umgebungsspezif ischen Quell - 
code fur jedes Regel sprachenmodul . Das Regelelement 94, Fig. 5, 
entlialt ein Attribut, das die Umgebungsbestitnmung fur jedes 
Regelmodul festlegt. Der Codeerzeuger 24, Fig. 2, nimmt die 
hoheren Regel spracnenanweisungen und ubersetzt sie in Quellcode 
in eine Sprache, die von der Hardwareutngebung der Bestimmung der 
Regel unterstutzt wird. Zum Beispiel wurde, falls eine Regel von 
einem Personal Computer auszufvihren ist, der nur die C-Sprache 
unterstutzt, der Codeerzeuger die Regelsprachenanweisungen in C 
ubersetzen. 

Falls die Regel sprachenanweisungen, die in einem Modul festge- 
legt sind, erfolgreicli in einen Quellcode umgewandelt werden 
konnen, wird dieser Code in Dateien in dem Endlager 4 ge- 
speichert. Falls es jedoch logische Fehler in den Regelspraclien- 
anweisungen gibt, wird kein Code gesichert und Fehlercaeldungen, 
die das erfolglose Ergebnis naher spezif izieren, werden in einer 
Fehlschlagdatei gesichert. 

Naclidem die Zubereitung durchgefuhrt worden ist, konnen detail - 
lierte Berichte uber jedes Element in dem Elemente-Beziehungen- 
Modell gegeben werden. Diese Berichte sind die technische 
Dokumentation eines Prograrams . 

Der Leser wird erneut auf Fig. 2A verwiesen, die ein Beispiel 
einer Umsetzung des Codeerzeugungsmoduls 24, Fig. 2, in der 
dreifach xuiterteilten Umgebung des Mainframe 1, des Mini- 
coTi5>uters 2 und des PC 3 wiedergibt. Bei diesem Beispiel maS der 
Quellcode fur jedes der Regelsprachenmodule nicht in der 
Hardwareumgebung erzeugt werden, die die Bestimmung jeder Regel 
sein wird; der Schritt des Konqpilierens dieses Quellcodes wurde 
jedoch in' der Bestimmungsumgebung der entsprechenden Regel 
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erfolgen. In der PC-Umgebung 3 konnte eine Ziibereitungs- 
einrichtung 59, Fig. 2A, z. B. Quellcode in der Sprache C fur 
jede vom PC ausfuhrbare Regel unter verwendung des Regel- 
sprachencodes und alle View-Pelder und Kon?>onentenf enster, die 
zu diesem Regelelement des Regeltnoduls zugehorig sind, 
ziabereiten. Die Zubereitungseinrichtung 59 konnte ebenso z . B. 
COBOL -Quellcode fur Regeln zubereiten, die zur Ausfuhrung auf 
dem Mainframe bestinimt sind. In der Mainf rame-Umgebung l stellt 
ein Mainframe Front -End-Modul 57 die Moglichkeit bereit, die 
Regelsprachenmodulanweisungen in Quellcodesprachenanweisungen zu 
ubersetzen, die von der Hafdwareumgebung der Bestimmung der 
Regel unterstutzt werden. pas System 88 HPS Front- End -Modul 56 
fulirt dieselben Aufgaben in einer Mikrocomputenamgebung aus • 

Urn bei dem Beispiel die Codeerzeugung durchzuf uhren, verwendet 
das Codeerzeugungsmodul in jeder Umgebung die Regelsprachen- 
module plus Inf ormationen, die von dem Elemente-Beziehungen- 
Modell benotigt werden. Um die Regel sprachenmodule zu transpor- 
tieren und Quellcodemodule fur die verschiedenen Umgebungen zu 
erzeugen, kann der Benutzer unter verwendung des Datenbank- 
administratormoduls (DBA) 44 die Moduldateien in das zentrale 
Endlager 4 laden und dann verschiedene Module 34, 46 verwenden, 
um die Inf orraationen zum Kompilieren in spezif ische Umgebungen 
herunterzuladen . 

In dem Fall einer Regel, die vorgesehen ist, von der PC-Umgebung 
3 aus in der Mainf rame-Umgebung l ausgefuhrt zu werden, stellt 
ein Haupt-View-Modul 3 6 iiber das Kommunikationsmanagermodul 8 
Zugriff auf die Mainf rame-Umgebung 1 bereit, wodurch ein nicht 
intelligenter Zugang in der PC-Umgebung emuliert wird. 

Von der PC-Umgebung 3 wird in diesem Beispiel Zugriff auf die 
Mikrocomputerumgebung 2 uber das View-Sprecher-Modul 46 bereit- 
gestellt, daS mit dem System 88 Front -End -Modul 56 unter Verwen- 
dung eines PC-Verbindungsmoduls 50 und eines Dateiubersetzungs- 
moduls 48 koramuniziert . Auf dieser Stufe der Entwicklung konnen 
alle erzeugten Quellcodeanweisungen eines Moduls mit einem 



Regel-view-Entstorer uberpruft werden, der der jeweiligen 
Umgebung zugeordnet ist. Der Regel-view-Entstorer ist ein Aspekt 
der Testeinrichtung 10 der vorliegenden Erf indung und wird unten 
vollstandiger beschrieben werden. Erfolgreich getestete Module 
konnen in dem zentralen Endlager 4 gespeichert werden . 

I . Zus aiTimenbau 

Wenn alle Quellcodemodule einer Anwendung an die jeweilige 
umgebung verteilt worden sind, mussen sie zu einetn laufenden 
Computerprogramm zusatranengebaut werden. Die Scbritte sind: 1) 
Kompilieren des Quellcodes in Objektcode; 2) Errichten von 
Kommunikationsroutinen, um eine Interaktion der Prograinmodule 
uber die Umgebungen hinweg zu ermoglichen; und 3) Binden bzw. 
Verknupfen des kompilierten Codes. 

Der Zusainmenbau muB in jeder Umgebung ausgefuhrt werden, in die 
Programmodule verteilt wurden. Zum Beispiel wird bei einem 
System, das eine PC-Verarbeitung einschlieSt , der PC einen 
Systemzusammensetzer 28, Fig. 2, auf dem PC aufweisen, der es 
einem Prograramierer ermoglicht, die Regeln auf dem PC zu 
konpilieren xind zu binden. 

In demselben Beispiel wurde ein separater Zusammenbau auf einem 
Minicomputer abgeschlossen werden mussen. Zum Beispiel auf einem 
IBM S/88 Oder stratus Minicomputer wurde ein Befehl wie "Build 
the Rule Router Application" die Grenzregeln nehmen und sie mit 
jedem anderen Regelmodul, das mit ihnen in der Mini-Umgebung in 
Beziehung steht, verknupfen. Die Funktion bindet den Code auch 
zu einem ausfuhrbaren Modul . 

Mainframe Programmodule werden separat zusammengebaut . Zum Bei- 
spiel bei der beispielhaf ten IBM-Umgebung, die von einem CICS- 
Betriebssystem und einer DB2 relationalen Datenbank unterstutzt 
wird, stellt ein Systemzusammenbauer 28, Fig. 2, auf dem 
Mainframe die Zusammenbauf unktionen fur den Regel- und 
Komponentenquellcode bereit . Bei einer Regel wurde ein 
Zusammenbauer : 



" verif izieren, dalS die Regel eine gultige Mainf rame-Regel 
ist ; 

verif izieren, daS die Regel den CodeerzeugungsprozeE 

abgeschlossen hat; 
7 den Benutzer abfragen, urn anzuzeigen, ob die Regel als 

Grenzregel aufzubauen ist; 
" die Bindungs-Datei lesen, um die On-line-Views-Datei und 

die On-line-Beziehungen^Datei fur die Lauf zeit-PCI- und 

Umwandlungsverwendung zu laden; 
" den Quellcode in die On-line-Quelldatei fur die Regel -View- 

Verwendung laden; 

automatisch die DB2-Bindung ausfiihren, basierend auf den 

Beziehungen, die gegenuber dem Endlager fur Grenzregeln 

festgelegt sind, welche die DB2-Aufrufe ausgebende Kompo- 

nenten verwenden; 
^ eine Liste von anderen Regeln und Kotnponenten anzeigen, die 

von dem Aufbau einer bestinimten Regel betroffen sind; 
" den Grenzregeln, die pB2-Aufi:ufe ausgebende Kotnponenten 

verwenden, eine einheitliche Bezeichnung und einen 

einheit lichen DB2-Plan-Namen zuordnen; 

einen DB2-Plan fiir eine Grenzregel neu binden, wenn eine 
der betroffenen Komponenten der DB2-Aufrufe ausgebenden 
Regel, verandert worden ist; 
" die Regel aus der Mainf rame-Umgebung entfernen, wenn die 
Regel nicht linger ben6tigt wird. 

Bin Komponentenzusatnmenbauer in einer Mainf rame-Utngebung wurde 
diese Funktionen ausfuhren: 

einem Programmierer die Einrichtungen zur Verfugung 

stellen, um seine Komponente in eine von dem System 

unterstutzte Sprache zu kompilieren; 
^ dem Programmierer erlauben, die Ergebnisse seines Kompi- 

lierens einzusehen (Kompilierungslisten und editierte 

verlcnupfungsabbildungen) ; 
" eine Liste von anderen Regeln und Komponenten anzeigen, die 

von dem Aufbau der "Speziellen Komponente beruhrt werden; 

dem Benutzer erlaxaben, den Quellcode einer Mainframe- 
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Komponente zu editieren* 
J. Aiisfiihruna 

Nach dem erf olgreichen Zusanimenbau der Anwendiingsmodule in jeder 
Hardwareumgebung kann das Prograram jetzt ausgefuhrt und getestet 
werden. Die CASE-Einrichtung stellt die MoglicWceit bereit, die 
Anwendung von jeder Umgebung in der Hardwarearchitektur aus 
auszufuhren und zu testen. Zum Beispiel hatte ein Programmierer 
bei verwendung der Hardwarearchitektur bestehend aus einem IBM 
Mainframe, einem IBM Stratus Minicomputer und PC-Arbeitsplatzen, 
wie in Fig. 1, an einem PC sitzend die Optionen: 

die PC-gestutzten Teile einer Anwendung auszufuhren, wobei 
keine Verknupfungen mit Modulen, die in der Stratus- oder 
Mainframe -Umgebung ausgefuhrt werden, erzeugt werden; 
die Module und die modulare Ausfuhrung in anderen Umgebun- 
gen zu testen. In diesem Fall werden Verknupfungen mit 
Anschlussen anderer Umgebungen erzeugt. Dies erlaubt 
Koramunikation zwischen dem Umgebungen; 
" das gesamte Programm auszufuhren bzw. zu testen. In diesem 
Fall werden Verknupfungen mit jeder der erf order lichen 
Ausfuhrungsumgebungen erzeugt. 

K. fiberarbe iten einf^r Anwendung 

Der Prozefi des Andems der Elemente bei einer Anwendung unter 
Verwendung des Elemente-Beziehungen-Modelliersystems und der 
Regelsprache ist ein geradliniger Prozefi, Es wird in die 
Datenbank eingetreten, und das Programme lement wird geandert. 
Kleine Anderungen in diesen Systemen konnen jedoch groEe 
Konsequenzen haben. Grundsatzlich mussen alle Elementtypen, die 
Elemente, die geandert worden sind, besitzen, verwenden oder 
einschlieEen, neu zubereitet bzw, «'modif iziert" werden. Die 
CASE-Einrichtung fuhrt diese Modifikation durch das Software- 
verteilungssystem 32, Fig. 2, durch. {Siehe die vorgenannte 
Internationale Anmeldung, die durch Bezugnahme inkorporiert 
wurde . ) 

li. Testeinr ichtunq 
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Letztlich stellt das CASE-System eine Entstor- und Testeinrich- 
tung bereit, die es dem Benutzer erraoglicht, die Leistungs- 
fahigkeit einer Anwendung zu ermitteln. 

Allgemein werden die Anwendungen zuerst in den Computer auf 
Codeniveau eingegeben. Traditionelle Codeentst6r-Tools sind zum 
Testen ausschlieSlich auf dem Codeniveau vorgesehen. Anstelle 
dessen stellt die CASE-Einrichtung der vorliegenden Erfindung 
ein Regel-view-Modul fur ein hoheres Entstoren bereit, was Teil 
der Testeinrichtung 10, dargestellt in Fig. l, ist. Eine Version 
des Regel-View wurde bei einer Hardwarekonf iguration in jeder 
der Betriebsumgebungen existieren. Anwendungen, die mehr als 
exne umgebung uberspannen, erfordern ein separates Testen der 
Module in jeder Umgebung • 

Anrufe des Regel-view-Moduls werden von der CASE-Einrichtung 
automat isch eingebettet, wenn Code erzeugt wird. Der Regel-View 
laSt die Anwendung in einem Entstorer auf Regelniveau laufen, 
der auftretende Fehler und Probleme lokalisiert. Er kann 
interaktiv verwendet werden, urn einen RegelprozeS durchzusehen 
und urn die inhalte eines View-Kopierbuchs an jedem Punkt zu 
uberpriifen. Der Regel-View gibt Programmierem die Mdglichkeit: 

1. die Ausfuhrung einer Regel einzuleiten; 

2. die Schnittstelle zwischen einer Regel und einer 
zweiten Regel oder Komponente zu unterbrechen; 

3. in die Logik einer Regel einzutreten; 

4. ein Regel- oder komponentenmodul durchzugehen; 

5. an den Beginn eines Moduls zuruckzugehen; 

6. jedes Feld innerhalb eines View, der von der aktiven 
Regel besessen wird, zu uberprufen und zu modifi- 
zieren; 

7. den Quellcode der aktiven Regel durchzusehen; 

8. jegliche View-Daten fur zukunftige Bezugnahme und 
wiederverwendung zu sichern; 

9. den Regelquellcode und View-Daten auszudrucken . 



Der Regel-Vxew wird an jedem Unterbrechungspunkt eine Liste 



aller Views, die uberpruft und editiert werden konnen, zusammen- 
stellen. Die Anzahl der angezeigten Views hangt davon ab, wo iind 
wie der Regel-View verwendet wird. In den meisten Fallen werden 
die Views, die zur Anzeige verfugbar sind, die Eingabe und 
Ausgabe der ausgefuhrten Regel enthalten. In weiter fortge- 
schrittenen. situationen wenh asynchrone Regeln entstort 

werden oder mehrfache Anwendungen getestet werden konnen 
viele Views zur Uberprufung verfugbar sein. Die Inhalte eines 
views konnen ausgedruckt oder in einer Datei gesichert werden. 

Der Regel -View- Editor erlaubt es dem Progratnmierer , jegliche 
Daten durch Verwend\ing eines Feldeditors zu editieren, Mit dem 
Feldeditor kann ein Progranmiierer jegliche Daten durch Uber- 
schreibeh der alten informationen Sndem. Der Editor erlaubt dem 
Benutzer auSerdem, die Inhalte jede.s Felds in ihre Originalwerte 
zu restaurieren. 

Urn einen Quellcode einer Regel zu revidieren, stall t ein Text- 
editor eine Option zur Verfugung, in der die Zeilen des Quell- 
codes, die aktuell ausgefuhrt wird, zu jeder Zeit hervorgehoben 
wird. Fails mehrere Module unter dem Regel-View laufen, ist der 
angezeigte Quellcode der Quellcode, der die Daten in dem 
aktuellen View besitzt. 

M. Softwareverteilu ng fQr allaemeine Anwendung 

Die vorangegangene Diskussion der CASE-Tool-Einrichtung der 
vorliegenden Erfindung war auf das Modellieren und die Entwick- 
lung einer einzigen Kopie eines Anwendungsprogramms beschrankt, 
das beispielsweise uber drei Hardwareumgebungen eines PC, eines 
Mikrocomputers und eines Mainframe verteilt wurde. Eine einzige 
Kopie der Module, die das Programm ausbilden, wurde an die 
geeigneten Hardwareumgebungen verteilt, xmd die Anwendung wurde 
entst6rt, und ihre Leistungsf ahigkeit wurde beurteilt. Nachdem 
die Anwendung jedoch getestet und fertig fur die allgemeine 
Anwendung ist, tmissen viele Kopien der das Programm ausbildendeh 
Module verteilt und gepflegt werden. Das Sof twareverteilungs- 
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modul 32 der vorliegenden Erfindung wird eine Vielzahl von 
KopiQn der Module einer Anwendung uber eine parallelverarbei- 
tende Hardwareumgebung verteilen, so dafi viele Benutzer dasselbe 
Progratnm benutzen konnen. Fur mehr Inf ormationen uber das 
Sof twareverteilungssystem siehe die vorgenannte intemationale 
Anmeldung. 

N. TTmwandlun a fur nicht-intelliQente gndqeyat;e (NITC) 

Zusatzlich zu der oben erwahnten Hardwarekonf iguration kann die 
CASE-Einrichtung der vorliegenden Erfindung auch unter Verwen- 
dung einer Hardwarekonf iguration umgesetzt werden, bei der der 
Endbenutzer des Anwendungsprogratnms keinen Zugang zu einetn 
verarbeitenden Endgerat, wie beispielsweise einem PC, hat. 
Stattdessen wurde der Endbenutzer nur Zugang zu einetn nicht- 
intelligenten Endgerat haben. Ein Beispiel ware ein Terminal 
3270 der Marke IBM, der an einen Mainframe Computer wie den IBM 
3 090 angeschlossen ist, der oben als beispielhaf te Aus- 
fuhrungsform beschrieben wurde. Es konnen aber auch andere 
geeignete Endgerat e benutzt werden, wenn die Erfindung in 
anderen Mainframe -Hardwareumgebungen umgesetzt wird, Ein nicht- 
intelligentes Endgerat wird manchmal verwendet, well es weniger 
teuer fur groSe Benutzergruppen beim Zugrif f auf einen einzigen 
Mainframe Prozessor ist, als jedem Benutzer seinen dder ihren 
eigenen Personal Prozessor zu geben. In diesen Fallen kann es 
jedoch sein, da£ die Programmierspezialisten weiterhin Anwen- 
dungen mit einem PC entwickein unter Verwendung derselben 
Entwicklungswerkbankmodule 34, wie sie in Fig. 2A beschrieben 
sind, entwickein wurden. Diese Entwicklungs -Tools erlauben es 
dem Programmierer zum Beispiel, Benutzerschnittstellendateien 
(beispielsweise Fensterdateien) aufzubauen, die in Verbindung 
mit der oben beschriebenen Umwandlungsf unktion der CASE- 
Einrichtung verwendet werden. Vorausgesetzt, daS der Endbenutzer 
in dem obigen Fall keinen PC hat> um die erzeugten Fenster 
umzuwandeln, ware die grafische Schnittstelle, die in den 
Fensterdateien beschrieben ist, sinnlos. 
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Die vorliegende Erfindung stellt dennoch eine Moglichkeit 
bereit, unter -Verwendung eines umwandlungsmoduls fxir nicht- 
intelligente ' Endgerate (NITC) 140, Fig. 2A, eine grafische 
Schnittstelle zu erzeugen. Das UmwandlungsmoduL fur nicht- 
intelligente Endgerate raacht es moglich, Anwendungen auf zubauen, 
die einem Endbenutzer, der beispielsweise eine nicht- 
intelligente, an einen Mainframe angeschlossene Vorrichtung 
- verwendet, grafische Benutzerschnittstellen anzeigen. Das 
umwandlungsmodul fur nicht-intelligente Endgerate kann auch 
bestehende PC-Arbeitsplatz-Sof twaremodule utnwandeln, so daS sie 
in einer Mainframe -Umgebung ausgefuhrt werden konnen. Durch 
Bereitstellen dieser Funktion der vorliegenden Erfindung kann 
unter Verwendung der Entwicklungswerkbankmodule 34 eine auf dem 
Mainframe ausgefuhrte Anwendung vollstandig innerlialb einer PC- 
umgebung entworfen, aufgebaut, entstort urid als Prototyp 
fertiggestellt werden, ohne vor der offentlichen Verteilung auf 
den Mainframe zuzugreifen. 

In dem Elemente-Beziehungen-Modell ist das Fens ter element 
weiterhin fur ein Fensterelement definiert, das fur eine 
grafische fienutzerschnittstelle auf dem Mainframe verwendet 
wird. 

In der PC-Umgebung ermoglichen es die Entwicklungswerkbankmodule 
34 einem Benutzer, die Fensterobjekte (Masken genannt) zu 
zeichiien, mit denen der Endbenutzer der Anwendung interagiert- 
Das Fensterzeichnermodul wurde oben diskutiert. 

Die Maske kann als zu dem Fensterelement zugehorige Datei in dem 
zentralen Endlager 4 gespeichert werden. Diese Masken mussen 
jedoch unter Verwendung von Bildschirmobjekten, die von der 
Endgerateumwandlungsvorrichtung fur nicht-intelligente Endgerate 
unterstutzt werden konnen, aufgebaut werden. 

Ein Fenster zur Ausfuhrung sowohl auf dem PC und dem nicht- 
intelligenten Endgerat kann z. B. durch Auswahlen einer Option 
in dem Fensterzeichnermodul 16 spezifiziert werden. Die Anwahl 



der Option wandelt das aktuelle Fenster in ein Format um, das 
den umwandlungsbildschirm des nicht-intelligenten Endgerats 
imitiert. Zum Beispiel konnten Felder in Reihen-/Zeilen- 
Koordinaten ubersetzt werden, Drucktasten konnten in die 
FuSzeile des Schirms verschoben werden und Tastaturaquivalente 
fordem. Das Auswahlen dieser Anwahl versetzt auSerdein das 
Fensterzeichnermodul in einen Maskenaufbaumodus fur nicht- 
intelligente Endgerate, der die Anordnung von neuen Objekten 
verhindert, die nicht von einer Endgerateumwandlungsvorrichtung 
fur nicht -intelligente Endgerate unterstutzt werden konnen, 

Der Hauptunterschied zwischen einem PC-Arbeitsplatz und einer 
nicht-intelligenten Endgeratvorrichtung ist, daS die Umwand- 
lungsvorrichtung fur nicht- intelligent e EndgerSte Textzeichen 
manipuliert , wahrend der PC-Arbeitsplatz grafische Pixel 
manipuliert , die dem PC-Arbeitsplatz ein hoheres MaS an 
Steuerfunktion verleihen. Um diesem Unterschied Rechnung zu 
tragen, konnte das Fensterzeichnermodul z. B. samtliche 
Textobjekte in einen Standardzeichensatz umwandeln. 

Die in der Mainframe -Umgebung erzeugten Fenster unterstutzen 
viele der Moglichkeiten, die bei PC-Umgebungs-Fenstern vorhanden 
sind, einschlieSlich beispielsweise Farben, editierbare Felder 
und Textfelder (beispielsweise nur zur Anzeige) , Feldanzeige- 
attribute (beispielsweise GroEe oder Art des Felds, Bereich 
usw.), Drucktasten und andere Funktionsschlusselacjuivalente . 

Dem Aufbau der Anwendung auf den PC-Arbeitsplatz f olgend, miissen 
die die Anwendung ausmachenden Objekte, in den Mainframe geladen 
werden, um fur die Ausfiihrung zubereitet zu werden, Der 
Lauf zeitanteil des Umwandlungsmoduls fur nicht -intelligente 
Endgerate managt alle Umwand lungs funk tionen und stellt die 
Einrichtungen fiir einen Entwickler bereit, um die Umwandlungs- 
funktionen dynamisch zu verandern. 

Die vornehmliche Funktion der Umwandlungsmodule ist es, die 
gesamte Eingabe und Ausgabe uber den Bildschirm des nicht- 



intelligenten Endgerats fur ein Fenster umwandelnde Kegel zu 
managen. Zusatzlich teilt das umwandlungsmodul fur nicht- 
intelligente Endgerate die Aktionen des Endbenutzers der Regal 
durch Besetzen eines ausgewahlten Felds mit der ausgewahlten 
Textfolge mit. Bevor die Eingabe des Benutzers an die aufrufende 
Regel ubertragen wird, fuhrt das umwandlungsmodul die notweiidige 
Editierung und Validierung jedes Eingabefeld aus, wie sie durch 
die in dem Endlager und der Fens terdefinit ion definierten 
Attribute festgelegt ist. 

Das Umwandlungsmodul fiir nicht- intelligente Endgerate wird 
jedesmal aufgerufen, wenn eine Regel ein Fenster umwandelt. Wenn 
eine Regel ein Fenster umwandelt, liest das Umwandlungsmodul fiir 
nicht-intelligente Endgerate eine vorbestimmte Datei ein, um die 
physikalischen Attribute des Fensters zu erhalten. Diese 
physikalischen Attribute werden verwendet, um die Datenstrom- 
befehle aufzubauen, die verwendet werden, um das Fenster auf 
einer nicht -intelligenten Endgeratvorrichtung anzuzeigen. 

Das umwandlungsmodul fur nicht -intelligente Endgerate fuhrt eine 
Editierung und Validierung von alien Eingabef eldem aus, bevor 
die Steuerung zu der aufrufenden Regel zuruckkehrt, Bei alien 
numerischen Feldem stellt das Umwandlungsmodul fur nicht - 
intelligente Endgerate sicher, daS die eingegebenen Daten 
numerisch sind und stellt die Stellenwertigkeit basierend auf 
einem eingegebenen Dezimalpunkt Oder dem implizierten Dezimal- 
punkt, der in einer numerischen Bildfolge festgelegt ist, ein. 

Zum Beispiel wird eine in das Feld eingegebene Folge 123, falls 
ein Dezimalfeld als funf Stellen lang mit zwei der Stellen 
rechts von dem Dezimalpunkt def iniert und unter Veirwendung einer 
numerischen Bildfolge "9999.9" editiert ist, die folgenden 
Resultate haben. Das Dezimalfeld wird den Wert 12.30 enthalten 
und das Bildschirmf eld wird 0012.3 anzeigen. Zusatzlich zur 
Verwendung numerischer Bildfolgen zum Editieren und Validieren 
numerischer Eingaben kann unter Verwendung des Fensterzeichner- 
moduls eine Bereichsgrenze gesetzt werden, um sicherzustellen. 



•I 




•••• 



48 

daS der eingegebene numerische Wert nicht jenseits der Minitnum- 
und Maximum- Wert e des festgelegten Bereichs liegt. 

Buchstabenf elder werden nur validiert, falls der Eingabewert mit 
einem Set von zulassigen Werten libereinstimmt . Dieser Set und 
seine Werte werden als Elemente gegenuber dem zentralen Endlager 
definiert. Um bei einem Feld festzulegen, daE es einen Set von 
zulassigen Werten anfordert, muS der Name des Setelements in dem 
Ref erenzdateiattribut des Felds festgelegt sein, wenn die 
Objekteditierf estlegungen des Felds unter Verwendung des 
Fensterzeichnermoduls getroffen werden. Das .Umwandlungsmodul fur 
nicht-intelligente Endgerate wird verif izieren, daS die 
eingegebene Buchstabenf olge in dem Set der zulassigen Werte 
enthalten ist, 

Bei jeglichen fehlerhaften Feldern wird das Umwandlungsmodul fur 
nicht -iritelligente Endgerate die fehlerhaften Felder markieren 
und eine Fehlermeldung anzeigen. Bei nicht-intelligenten 
Vorrichtungen, die Farbe unterstutzen, konnen die fehlerhaften 
Felder hervorgehoben werden. 

Wie f ruber f estgestellt , konnen die Drucktastenobjekte auf einem 
PC-Arbeitsplatz-Fenster als Funktionstasten auf der nicht- 
intelligenten Endgeratvorrichtung umgesetzt werden. Jede 
Funktionstast^e, die fur ein Fenster definiert ist, hat einen ihr 
zugehorigen Textwert. Dieser Textwert wird von dem umwandlungs- 
modul fur nicht-intelligente Endgerate an die aufrufende Regel 
in ein bestimrates Feld zuruckgegeben . 

Die oben beschriebene Ausf uhrungsf orm der Erf indung ist nur zur 
Erlauterung vorgesehen, da bestimrate Anderungen an ihr ausge- 
fiihrt werden konnen, ohne von der klaren Lehre der Erf indung. 
abzuweichen. Dement sprechend ist auf die nachf dlgenden Anspruche 
zu verweisen werden, die die Erf indung vornehmlich defihieren. 
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Application No.: 91 901 023,1 

Applicant: Seer Technologies, Inc. 

8000 Regency Parkway 
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ANHANG A: KEGELS PRACHENSYKTAX 
Token der Regelsprache 

Token sind di& Atome, aus denen eine Progratraniersprache aufge- 
baut ist, Alle reservierten Worter , so wie IF, AND, FROM, 
stehen fur Token der Regelsprache . Andere Beispiele sind 
spezielle Symbole wie ")" (rechte Klanmier) , "<=" (weniger oder 
gleich-Verhaltnisoperator) und dergleichen. Letztlich wird man 
auch Token, so wie DICT_View (View-Name) , begegnen, die 
Bezugsquellen aus dem Endlager bezeichnen. 

Reservierte Worte 



ABS 


EVERY 


OVERLAY 


ALL 


EXISTS 


PC 


AND 


EXP, EXP 10 


PREV 


ASCENDING 


EXTERN 


PUT 


ASYNCH 


EXTRACT 


QUEUE 


ATTACH 


FALSE 


REFRESH 


AVG 


FIELD 


RETRIEVE 


BEEP 


FLASH 


RETURN 


BY 


FORALL 


RIGHTJ 


CASE 


FROM 


ROUND 


CHAR 


IF 


ROUTE 


CICS 


IN 


RULE 


CLEAR 


INDEX 


SET 


COMPONENT 


INSET 


SETERROR 


CONVERSE 


INTEGER 


SMALLINT 


CURRENT 


LEFTJ 


SPACES 


DCL 


LENGTH 


SQL 


DELETE 


LIKE 


SQRT 


DEPENDING 


LOG, LOGIC 


STRATUS 


DESCENDING 


MAP 


STRING 


DETACH 


MAX 


SUBSTRING 


DIV 


MIN 


SUM 


DO 


MOD 


TO 


DOMAIN 


MODULE 


TRIM 


ELSE 


MOVE 


TRUE 


EMPTY 


NEST 


TYPE 


ENDCASE 


NEXT 


USE 


ENDDCL 


NOT 


VIA 


ENDDO 


NUMERIC 


VIEW 


ENDEXTERll 


OCCUR 


WHILE 


ENDFORALL 


OF 


WINDOW 


ENDIF 


ON 


ZERO 


ENDSET 


OR 


ZEROES 




Reservierte Symbole 



Zeichen 


Bes chr e IbimQ 


Symbol 


*> 


linke Bemerkung 




<*• 


rechte Bemerkung 




( 


linke Klammer 


LP 


) 


rechte Klammer 


RP 




gleich 


EQ 


> — 


grofier oder gleich 


G£ 


> ■ 


groEer als 


GT 


< = 


kleiner Oder gleich 


LE 


< 


kleiner als 


LT 


< > 


nicht gleich 


NE 




Komma 


COMMA 


# 


Semikolon 


SEMI 



Endlager e 1 emen tbe z e i chnungen 

MODULE_NAME 

RULE_NAME 

WINDOW^ISFAME 

VIEW__NAME 

SYMBOL_NAME 

SET NAME 



Vor r ang t ab e 1 1 e 

Die folgende vorrangtabelle listet den Vorrang bzw. die 
Bindungswirkung der Regelsprachenoperatoren in ansteigender 
Ordnung auf . Operatoren, die in derselben zeile auftreten, haben 
untereinander dieselbe. Bindungswirkung. 

links nach rechts 
links nach rechts 
rechts nach links 
nicht- as soziativ 
nicht -assoziativ 
links nach rechts 
ni ch t -as soziativ 
rechts nach links 

The rechte Spalte beschreibt die Assoziativitat der Operationen. 
Aus der "AND" -Zeile der vorstehenden Tabelle ist zu entnehmen, 
daS es vollig zulassig ist, fur Bedingungen condl , cond2, cond3 
2u schreiben 

condl AND cond2 OR cond3 

und daS die implizierte Ordnung bzw. der syntaktische Aufbau 
zuerst 

condl AlvTD cond2 



OR 

AND 

NOT 

EQ NB LE LT GE GT 

INSET 

MINUS 

IN 

OF 



und anschliefiend 



cond2 AND cond3 

ist . 

Anderes Beispiel : Gegeben sei eine teilweise Qualif ikation 
VI OF V2 OF V3 

die drei views VI, V2, V3 einbezieht, dann erkennt der syntak- 
tische Analysierer zuerst 

V2 OF V3 

und anschliefiend 

VI OF V2. 



• • • • • • • 
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ANHAN6 B: RE6ELSPRACHENGRAMMAT1K (BMF) 



rule_code : 

del s-list: 
I 

dcl_stTnt : 
del 1st: 



del item: 



dcl_idx-itein: 
dcl__chr_iteTa: 
del_int_iteiii : 
dcl_l ike^item : 
dcl_ext_it:ein : 
dclvar list: 

~ I 

dclvar item: 

" I 

chrtype : 



1 

inttype: ^ 

like type: 
dcl_subscr : 
dicttype: 
stmt list: 

~ I 

stmt: 



dcl_s_list stmt_list 
empty 

dcl_s_list dcl_stmt 
DCL dcl_lst ENDDCL 
dcl_item 

dcl_lst dcl_item 

dcl_icix_item 

dcl_chr_itein 

dcl_int_item 

dcl_li)ce_item 

dcl_ext_item 

dclvar_list INDEX SEMI 
dclvar_list chrtype SEMI 
dclvar_list inttype SEMI 
dclvar_list liketype SEMI 
extern dclvar_list decttype SEMI 



dclvar_item 
dclvar list 



COMMA dclvar item 



simple_var 

s imp 1 e_var dcl_subscr 
CHAR 

CHAR dcl_subscr 

SMALLINT 
INTEGER 

LIKE simple_var 
L,P int_lit RP 
SET 



(empty) 
stmt list 



stmt 



assign_stmt 
overlay-stmt 
clear stmt 
use stmt 
return_stmt 
converse_stmt 
async_stmt 
cond_stmt 
do stmt 




I 

ass ign_st:Tnt : 
over 1 ay_s tmt : 
clear_stmt: 
use stmt: 

I 

nest clause: 

" I 

r eturn_stmt : 
converse__stint : 
window_clause : 
async_stiT\t : 

1 
I 

attach detach: 

~ I 

refresh stmt 



view clause: 

" I 

field clause: 

" I 

occur clause: 

1 

beep-clause : 

I 

flash clause: 

" I 

cond stmt: 

I 



• • * 

• • * • 
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do_idx_stmt 

MAP expr TO variable 

OVERLAY dat_item TO variable 

CLEAR variable 

USE MODULE MODULE_NAME 

USE RULE RULE_NAME nest clause 

(empty) 
NEST 

RETURN 

CONVERSE window_clause 
WINDOW WINDOW_NAME 

ASYNC attach_detach RULE^NAME VIA RULE 

RULE__NAME 

ASYNC ROUTE RULE RULE_jNAME TO RULE 
RULE_NAME 

ASYNC refresh_stmt 

ATTACH 
DETACH 

REFRESH window__clause 

f ield_clause 

view_clause 

occur_clause 

beep_clause 

f lash_clause 

(empty) 

VIEW data_item 

(empty) clause 
FIELD data_item 

(empty) 

OCCUR data_item 

(empty) 
BEEP 



(empty) 
FLASH 

if_stmt 
case of-stmt 





if -stmt ; 

I 

case of stmt: 

" "I 

caseof_var : 
case list: 

" 1 

single_case: 
case_lit list: 



do stmt: 

I 

do_idx_stmt : 
do_clauses: 

from clause: 

" I 

to-clause: 

I 

by_clause: 
index clause: 

" I 

while clause: 

" I 

cond: 

s imp 1 e_c o nd : 
rel_op: 



54 




IF cond stmt-list ENDII 

IF cond stmt_list ELSE stmt_list ENDIF 

CASE_OF caseof_var case_list ENDCASE 
CASE_OF caseofvar case_list CASE OTHER 
stmt_list ENDCASE 

variable 



single_case 

case_list single_case 

CASE case_lit_^list stmt_iist 

lit 

set^const 
MINUS int_lit 
MINUS dec_lit 
case_lit_list lit 
case_lit_list set^const 

DO stmt_list WHILE cond stmt_list ENDDO 
DO stmt_list ENDDO 

DO do_clauses stmt_list while_cljause ENDDO 

from_clause to_clause by_clause 
index_clause 

(empty) 
FROM expr 



TO expr 



BY expr 

INDEX variable 



WHILE cond stmt_list 

simple_cond 

LP cond RP 

not cond %prec NOT 

cond AND Gond %prec AND 

cond OR cond %prec OR 

expr rel_op expr 
expr INSET SET_N7^E 

EQ 
NE 

num_rel_op 



I 

■I 



nuin_rel_op : 



variable: 



subscr_unit : 
item list: 



qual var list; 

" T 

dat item: 



set const: 

I 

lit: 



« • • • • • 

• • • • 
« • • 
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LT 
LE 
GT 
GE 



simple-var 

qual-id qual_var_list 

simple_var subscr_unit 

qual_id qual_var_list subscr^unit 

LP item_list RP 

expr 

expr COMMA expr 

expr COMMA expr COMMA expr 

OF VIEW_NAME 

qua'l_var_list OF VIEW_NAME 

variable 
lit 

set_const 
SYMBOL_NAME 

SYMBOL_NAME IN SET_NAME 

char_lit 
int_lit 
dec lit 
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AKHANG C: RS6EIiSPRACHENSEMA29TXK 

Bezeichniingeii 

Bezeichnungen warden verwendet, urn bestimmte Sprachkonstrukte zu 
benennen, so wie Variablen (z. B. Felder und Views) und andere 
Endlagerelemente, so wie Regain und Komponenten . 

Eine Feldbezeichnung muB mit einem alphabet is chen Zeichen 
beginnan. Ihm folgt optional eine Seguenz von einem oder. 
mehreren Buchstaben, Zahlen oder Unterstrichen . Zwischen 
GroSschreibung und Kleinschreibung wird kein Unterschied 
gemacht; deshalb benennen eine_lange_bezeichnung und 
EINE LANGE_BEZEICHNUNG dieselbe Sache, soweit die Regelsprache 
betroffen ist. Eine Bezeichnung kann keine "weiEen Felder" 
enthalten (Leertasten oder Tabulatoren oder neue Zeilen) . 

Man kann Namen fur Bezeichnungen verwenden, die reservierte 
Worte innerhalb der Sprache COBOL oder C oder jeder anderen 
Sprache sind (so wie SENTENCE oder SIZE) . Es ist jedoch zu 
beachten, daS bestimmte Worte als Schlusselworte oder fur 
zukunf tige Erweiterungen der Regelsprache reserviert worden smd 
(siehe Anhang A) . AuEerdem gelten fur die Bezeichnungen 
Beschrankungen beziiglich ihrer Lange, abhangig davon, was sie 
benennen. Diese Beschrankungen sind in Fig. 1 aufgelistet. 

Bezeichnungstyp Maximale Anzahl der Zeichen 




Feld 
View 
Symbol 
Set 

Fenster 
Regel 

Komponente 

Fig- 1 Langenbeschrankungen der Bezeichnungen 

Anhang A enthalt eine Liste von "reservierten Worten" fiir die 
Regelsprache, Diese Bezeichnungen konnen nicht verwendet werden, 
urn irgendein anderes Sprachenkonstrukt zu benennen, so wie 
Felder, Views, Regeln, Komponenten usw, . 

Opera tor en und Begrenzer 

Die folgenden Zeichen haben besondere . Bedeutung fur die Regel- 
sprache und werden als binare und unare Operatoren verwendet. 



18 
8 
18 
8 
8 
7 
7 



V 
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Symbol 


Name 


Funktion 


{ 
) 


linke Klammer 
rechte Klammer 


Grupp i e rxing ; 
Tief indizes 




Gleichheitszeichen 


zum Bilden von Symbolefi oder 
Ve rhal tni soperat oren 


< 


kleiner als-Zeichen 




> 


groSer als-Zeichen 




<> 


ungleich-Zeichen 


Test auf Ungleichheit 


<= 


kleiner als- oder 
gleich-Zeichen 


Test auf kleiner als 
Oder gleich 


>— 


groEer als- oder 
gleicli-Zeiclien 


Test auf groSer als 
Oder gleich 




Mi nus z e i chen 


Verneinung 




Komma 


Trennung von Listeneelementen 
und Tief indizes 




Semikolon 


Beendigung einer Erklarung 
eines lokalen Felds 




Addition 


zur zukunftigen Verwendung 


* 


Mult iplikat ion 


II 11 II 


/ 


Division 


II fi II 


+ + 


Ve re inigung 


II II II 


* * 


Unterteilung 


If II II 




Satzunterschied 


II II It 


< < 


Untersatz 


n n tt 


> > 


Ubersatz 


II II II 



Fig, 2 Binare und unare Regelsprachenoperatoren 
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Felder 

Ein Feld ist eine Variable, die sich wie ein Atom verhalt; das 
heist, sie kann nicht in kleinere Einheiten unterteilt werden. 
Mit der Ausnahme einer begrenzten Moglichkeit zur lokalen 
Erklarung von Feldern gegeniiber einem Regelprogratnm warden 
Felder unter Verwendung der Einrichtungen des HPS-Endlagers 
definiert. Sie werden nicht innerhalb einer Regel def iniert . 
Einige Beispiele von Feldern und deren Typen folgen. 

FLD_1 S^4ALLINT 

WORD_COUNT INTEGER 

In dem oben gegebenen Beispiel ist fld_i eine zwei Byte 
(relative) ganzzahlige Variable, und word_COUNT ist eine vier 
Byte (relative) ganzzahlige Variable. 

FLD_2 CHAR 

CUSIP_DESCR CHAR (20) 

FLD_ und CUSIP_DESCR sind Zeichenf elder der Langen 1 bzw. 20. 

CUST_BAL_AMT DECIMAL (15, 2) 

CUST_BAL_AMT ist eine "Dollars und Cents" -Variable mit bis zu 15 
Stellen Genauigkeit, von denen zwei auf der rechten Seite eines 
implizierten Dezimalpunkts angeordnet sind. DECIMAL (p,q) -Felder 
sind relative GroSen. 

CASH_TXN_BAL_AMT PIC S9999V99 . 

CASH__TXN_BAL_AMT und CASH_TXN_CR_AMT sind beides nutnerische 
Variablen tnit bis zu 4+2 = 6 Stellen Genauigkeit, von denen zwei 
auf der rechten Seite eines implizierten (V=" virtuellen" ) 
Dezimalpunkts angeordnet sind. Das S in dem ersten Beispiel 
bezeichnet ein optionales vorzeichen, wahrend in der Erklarung: 

CASH_TXN__CR_AMT PIC 9999V99 

CASH_TXN__CR_AMT nicht negativ sein kann. 

TEMP_BUFFER VARCHAR (50) 

Die Konstinikte der Regel sprache unterscheideii einen temp_buffer 
nicht von einer CHAR (SO) Variablen. Sowohl CHAR (50) als auch 
VARCHAR (50) ordnen 50 Byte Speicher zu, und in beiden Fallen 
wird alles, was in einen von ihnen eingebracht wird, linksbundig 
angeordnet und nach rechts mit Freiraumen aufgefiillt. Eine 
VARCHAR (n) Variable halt die Spur ihrer "aktuellen" Lange durch 
Verwendung eines separaten Langenfelds, welches fiir den Regel- 
sprachenprogrammierer vollstandig transparent ist. 

Die folgende Tabelle fafit die Feldtypen zusammen, die in der 
HPS-Regelsprache unterstiitzt werden, und einige ihrer 
Eigenschaf ten : 
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Bemerkungen 

Bemerkungen sind zwischen "*<" und als Begrenzungen einge- 

schlossen. Bemerkungen konnen nicht verschachtelt werden. Es 
gibt keine Grenze fur die Lange einer Bemerkung. 

*> Dies ist ein Beispiel einer Bemerkung <* 

*> Dies ist <* *> ein anderes Beispiel <**> 
. einer Bemerkung <* 

*> 

* es ist 

* zulassig, 

* eine Bemerkung 

* uber mehr als 

* eine Zeile ' zu verteilen 

* und * Oder < in Alleinstellung zu verwenden 
<* 

Eingabe nach Spalte 72 wird als Bemerkung behandelt (d. h. 
ignoriert) . 

Datengrdfien 

Datengrofien sind die variablen und Konstanten in der Regel- 
sprache. Fig. 3 zeigt, wie diese DatengroSen in Bezxehung 
zueinander stehen. 

DatengroSe 

variable 



Feld 
- View 



Konstante 

Literal 



Zeichenliteral 
numerisches Literal 



Setsymbol 



Fig- 3 DatengroSenhierarcliietabelle 



variablen 



variablen werden definiert unter Verwendung der View- und Feld- 
HPS-Elemente. Felder und Views werden unter Verwendung der 
Einrichtungen des Endlagers auEerhalb der Sprache selbst defi- 
niert und beschrieben. Es ist zu anzumerken, daS mit bestimmten 
Beschrankungen, Felder und Views mittels des^ DCL-Konstrukts 
lokal gegenuber dem Regelblock erklart werden konnen! 



Typ- 



Darstellung (1) 



Zeichen/ Anmerkung 
Nuiraner 



Zeichen CHAR (nn) Zeichen (2) 

Zeichenvariable VARCHAR (nn) Zeichen (3) 

2 -Byte Ganzzahl SMALLINT Zahl (4) 

4-Byte Ganzzahl INTEGER Zahl (4) 

Dezimalzahl DECIMAL (p,q) Zahl (4) 

relatives Bild PIC S9999999v9999999 beides (5,6) 

p Anzahl q Anzahl 



Axi2ner]c\in.gen : 

(1) "Darstellung" bezieht sich auf das Format der DCL . . . 
ENDDCL-Anweisungen fiir eine Variable jenen Typs . Es ist 
anzumerken, daS die aktuelle Version von HPS lokale 
Erklarungen fur die Datentypen CHARACTER, VARCHAR und 
sowohl SMALLINT iind INTEGER Variablen unterstvitzt. DECIMAL 
wird nicht unterstvitzt. Siehe Abschnitt 4 (Feldelement- 
typen) fiir weitere Inf ormationen beziiglich der Datentypen. 

(2) CHAR ist das gleiche wie CHAR (1) . 

(3) VARCHAR ist das gleiche wie VARCHAR (1) • 

(4) Ganzzahl- und Dezimalzahl variablen sind relative Variablen. 

(5) Relative Bildvariablen sind relativ, nicht relative Bild- 
variablen sind nicht relativ. 

(G) Bildvariablen sind von doppelter Natur. Sie benehmen sich 
wie numerische Variablen aufier in den folgenden Fallen, in 
denen sie sich wie CHAR- (nn) Variablen verhalten: 

Wenn sie mit Feldern oder Konstanten des Typs CHAR 
Oder VARCHAR Oder Views verglichen werden. 
Wenn sie als Quelle einer MAP oder OVERLAY -Anwei sung 
erscheinen, deren ziel exn Feld des Typs CHARACTER 
Oder VARCHAR Oder ein View ist . 

Views 

Die von der CASE-Einrichtung der vorliegenden Erfindung verwen- 
deten Daten sind in hierarchischen Strukturen organisiert. Zum 
Beispiel ist ein Unter-View der Vorganger eines Felds. 

Zur Erleichterung der Dokumentation werden Views von links nach 
rechts in ausgeschriebener Form wiedergegeben anstelle der gra- 
fischen von'oben nach unten Methode . Der oberste (am weitesten 
links befindliche) Knoten wird auch als der "01-Level View" 
bezeichnet (eine COBOL und PL/l Konvention) . 

Die folgende Datenstruktur weist VW_1 als ihren 01-Level View 
auf. VW_1 besteht aus den Nachf olger-Views CG_VW_11, CG_VW_13 
und CG_VW_10, und den Feldern CUSIP_DESCR, CUST_BAL_AMT und 
CASH_TXN_BAL__AMT . Der Nachnachf olger- View (auch bezeichnet als 
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NachfoLger-view oder Nachfolger von) CG_VW__13 von VW_1 is aus 
CG DATE, SUB_VIEW, CG_BIT auf gebaut . Der Nachfolger SUB_VIEW yon 
CG'"vw_13 weist die Felder CGVARCHAR und CG_CHAR, aber keine 
unt^ergeordneten Views auf . 



VW-1, 



CG VW 11 



CORDATE 
CG_VARCHAR 
CG_CHAR 
CG BIT 



CG_W_13, 



CG_DATE 
SUB_VIEW 

CG_VARCHAR 
CG_CHAR 
CG_BIT 

CUSIP_DESCR 
CUST_BAI._AMT 
CAS H_TXN_BAIi_AMT 

CG VW 10 



CHAR 
VARCHAR 
CHAR 
CHAR 



CHAR 
(05) 

VARCHAR 

CHAR 

CHAR 



(08) , 
(10) , 
(10) , 
(01) , 



(08) , 

(10) , 
(10) , 
(01) , 



*>tritt 5 X auf<* 



CHAR (20) , 
DECIMAL. (15, 2) , 
PIC S9999V99, 



SUB_VIEW (05) , 

CG_VARCHAR VARCHAR 
CG_CHAR CHAR (10) 

INT_RATE DECIMALi 
CG BIT CHAR 



*>tritt 5-tnal auf<* 
(10) , 

(7,7) , 
(01) , 



Pig. 5 Datenstmiktur eines Views 

Der obige View, VW_l, erlautert viele der Konzepte der zugrunde- 
liegenden HPS-Datenstrukturen . Jeder der unter-views, der zu der 
obigen Baumstruktur gehort, ist seinerseits eine Baumstruktur , 
bei der er der 01 -Level View wird. Zum Beispiel definiert 
CG VW_10 einen Baum mit CG_VW_10 als oberster Knoten, SUB_VIEW, 
INT RATE und CG_BIT als seine Blatter und Knoten vom zweiten 
Level und CG_VARCHR und CG_CHAR als seine Blatter vom dritten 
Level . 

Ein View ist durchgangig innerhalb des Endlagers durch den Namen 
seines 01-Level Knotens festgelegt. Mit anderen Worten steht 
VW_1 fur die gesamte Saramlung aller Views und Felder in der 
Figur . 

Views und Felder konnen mebr als einmal innerhalb eines Baums 
auftreten. Es ist ihnen aber nicht erlaubt, durch Bezugnahme auf 
sich selbst weder direkt noch durch eine Kette von dazwischen 
liegenden Nachfolger- oder Vorganger-Views rekursive Konstrukte 
zu bilden. 
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zum Beispiel ist CG_CHAR ein Feld, und SUB_VIEW ist ein view, 
die jeweils mehr als einmal innerhalb von VW_l auftreten. 

Es ist anzumerken, daS gemaE Paragraph 1, SUB_VIEW dieselbe 
Baumstruktur definiert, unabhangig davon, ob er als Nachfoiger 
von CG_VW_10 Oder CG_VW_i3 auftritt. 

SUB_VIEW (05) , 

CG_VARCHAR VARCHAR (10) , 

CG_CHAR CHAR (10), 

Fig* 6 Unter-View Datenstruktur 

Das Feld CG_CHAR, das zu detn view .SUB__VIEW gehort, der zu dein 
View CG_VW_10 gehort, kann andere Daten als das Feld CG_CHAR 
enthalten, das zu SUB_VIEW gehort, der zu CG_vw-13 geliort . 
Tatsachlich belegen sie unterschiedliche Speicherorte . Weiterhin 
erscheint CG_CHAR auch anderswo es ist auch eine Kotnponente 
von CG_vw_ll. Wie halt man diese Dinge innerhalb eines Regel- 
programms auseinander? 

Zuerst schreibt man den vollen qualif izierten Namen der als 
doppeldeutig bestiramten Gegenstande nieder (die entweder Felder 
Oder Views sein konnen) . Der voile qualif izierte Namen beginnt 
mit dem Namen der DatengroSe auf dem niedrigsten Level (die 
entweder ein Feld oder ein view sein kann) und arbeitet sich zu 
der Spitze des Baums unter Benennung jedes views (nicht Felds) 
und Trennen jedes der Namen mit dem reservierten Wort OF hoch. 
(Diese Benennungskonvention ist COBOL entlehnt und unterscheidet 
sich von derjenigen, die in C und ' PL/ 1 verwendet wird.) Zum 
Beispiel haben wir im Fall von CG_CHAR 

CH_CHAR OF SUB_VIEW OF CG_VW_11 OF VW_1, 
CG__CHAR OF SUB_VIEW OF CG_VW_13 of VW_1 und 
CG_CHAR OF CG_VW_10 OF VW_1 

Fig. 7 Voile qualif izierte Namen 

Die grundsatzliche Notation ist die folgende: 

X sei ein Feld oder view, das/der einen vorganger VI hat, 
der einen Vorganger V2 hat . . . usw. . 

Vn bezeichne den obersten Knoten ... 

Dann ist der voile qualif izierte Name von X: 

X OF VI OF V2 . . . OF Vn . 

Diese vollen qualif izierten Namen sind ausreichend, um zwischen 
den Fallen von CG^CHAR zu unterscheiden . Tatsachlich enthalten 
sie redundant e Inf ormationen fur den Regelcodeerzeuger , um 
zwischen den Fallen zu unterscheiden. Um die notwendigen und 
ausreichenden Inf ormationen zu erhalten, kann man die Namen der 
Views, die den vollen qualif izierten Namen gemeinsam sind, 
einfach streichen. Naturlich darf man nicht die Namen an der 
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Basis des Wegs auf warts zu dem obersten Level View streichen. 
Wendet man dies auf das obige Bei spiel an, ergibt sich: 

CG_CHAR OF CH_VW_11 

CH_CHAR OF CG_VW_13 und 

CG_CHAR OF CG_VW_10 

Fig. 8 Editierte qualif izierte Namen 

Dies ist die minimale Information, die der Regelcodeerzeuger 
benotigt, um zwischen den Fallen von CG_CHAR zu unterscheiden. 
Weiterhin ist dies auch die minimale Information, die ein Auge 
braucht, um die Falle mit einem Blick auf eine Darstellung von 
vw_l zu untersciieiden. 

Es gibt jedbch einen Typ von Doppeldeutigkeit , der nicht mit 
vollem qfualif izierten Namen gelost werden kann, falls qualifi- 
zierte Teilnamen erlaubt sind. Man betrachte die folgende View- 
Struktur : 

VIEWIO 

FIELDl, *>erstes Auftreten von FIELD1<* 

VIEWl, 

FIELDl *>zweites Auftreten von FIELDl<* 

— — FIELD2, *>erstes Auftreten von FIELD2<* 
VIEW2 , 

I FIELD2, *>zweites Auftreten von FIELD2<* 

Fig. 9 Zweideutige Feldstruktur 

VIEWO enthalt FIELDl als eine zweideutige Bezugnahme, weil die 
einzige vemunftige Wahl fur (teilweise qualif izierte) Namen fur 
das erste Auftreten entweder: 

FIELDl Oder FIELDl OF VIEW 10 

ist, aber beide Namen auch auf das zweite Auftreten von FIELDl 
Bezug nehmen. Im Gegensatz dazu ist zu bemerken, daS man einen 
deutlichen Unterschied zwischen den inhalten von 

FIELD2 OF VIEWl und FIELD2 OF VIEW2 

machen kann. 

Tiefindizes 

Die Regelsprache unterstiitzt Views mit Tiefindizes (das OCCURS- 
Attribut der view-View/HPS-Beziehung) . Sie sind die Gegenstucke 
zu Tabellen in COBOL und Arrays in C oder PL/l. 

Angenommen, daS vw_2 ein in dem HPS-Endlager wie folgt definier- 
ter View ist: 

VW 2 



CG VW 11 



(8) 



*>tritt 8-mal auf<* 



DATE 




VARCHAR 


(io) , 


CHAR 


(10), 


CHAR 


(10), 


(10) , 


*>tritt 10-mal auf<* 


DATE 




(05) , 


*>tritt 5-mal auf<* 


VARCHAR 


(10) , 


CHAR 


(10), 


CHAR 


(01), 


vArchar 


(10) , 


CHAR 


(10), 


CHAR 


(01) , 
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CG_DATE 
CG_VARCHAR 
CG_CHAR 
CG_BIT 

CH_VW_13 

CG_DATE 
CG_SUB_VIEW 

CG_V7VRCHAR 

CG_CHAR 

CG_BIT 

CG^VW^IO 

CG_VARCHAR 
CG_CHAR 
CG__BIT 

Fig. 10 View mit Indizes 

Bei jedem Auftreten von vw_2 gibt es 8 Falle von CG_w_ll (und 
alien ihm untergeor(±neten Feldern) , 10 Falle von CG_VW_13 (und 
alien Feldern und Views darunter) und 5 Falle von CG_SUB_VIEW, 
die jedem der 10 Falle vori CG_VW__13 nachgeordnet sind. 

Anmerkung: Eine Auf trittshauf igkeitsklausel ist kein Besitz 

eines Viewelements, sondem der Beziehung (OWNS) , die zwischen 
einem View und einetn anderen erzeugt wurde . 

Unter Verwendung des Beispiels in Fig. 10 kann auf CG_CHAR Bezug 
genoinmen werdeh wie f olgt : 

1. CG_CHR OF CG^SUB^VIEW OF CG_VW_13 OF VW_2 (SI) 

2. CG_CHR OF CG_SUB_VIEW OF CG_VW_13 OF VW-2 (SI, S2) 

3. CG_CHR OF CG_SUB_VIEW OF CG_VW_13 OF VW-2 (SI, S2, S3) 

wobei SI, S2, S3 die Tief indizes von VW_2, CG_VW_13 bzw. 
CG_SUB_VIEW bezeictuien. Es ist f estzustellen, dafi in konventio- 
neller Ausdrucksweise die obige Zahl 1 einetn zweidimensionalen 
Array entspricht, die obige Zahl 2 einem eindimiensionalen Array 
und die obige Zahl 3 einer Einf eldgroSe . 

Keinem Feld, das in der Regelsprache verwendet wird, ist es 
erlaubt, mehr als drei (3) Auf trittshauf igkeitsattribute in 
irgendeinem seiner Qualif ikationswege aufzuweisen. Es ist auch 
anzutnerken, dalS die Tief indizes so geschrieben sind, daE der am 
weitesten links bef indliche Index dem obersten view mit mehr- 
fachem Auftreten entlang des Pfads von X zu Vn entspricht. 

Ein view kann bis zu 2 0 Levels tief geschachtelt werden. Mit 
anderen worten, falls die Levelnuramern wie folgt ansteigen: 

01 03 . 05 07 . . . 

ist die hochste unterstiitzte Levelnummer 39. 



Konstanten 
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Konstanten treten in der Regelsprache in zwei Manif estationen 
auf : 

. Liiterale und 
, Setsyinbole. 

Sie konnen reprasentieren : 

, Zeichen, wie beispielsweise "New York City" , oder 

. (relative) ganze Zahlen, so wie 123 oder 1234567, Oder 

. (relative) Dezimalzahlen, so wie 123.45 oder 1234.50. 

Ntimerische Literale 

Es gibt zwei Arten von numerischen Literalen, Ganze Zahlen und 
Dezimalzahlen. Eine Ganzzahl ist eine Folge von einer oder 
mehreren Stellen. Eine Dezimalzahl ist eine Folge von einer oder 
mehreren Stellen gefolgt von einem Dezimalpunkt , dem 0 oder mehr 
Stellen folgen konnen. Eine negative Zahl wird ausgedruckt, 
indem ein Minus zeichen den Stellen voransteht . 

Zum Beispiel sind 0 und 123 Ganzzahlen. 123.0, -7734.33 und 
123,456 sind gultige Dezimalkonstanten ebenso wie 0.456. 

Fur diese Literale bestehen abtiangig von ihrem Typ (Ganzzahl 
Oder Dezimalzahl) Beschrankungen bezuglich der Anzahl der 
Stellen, die sie enthalten. Ganzzahlen bestehen aus bis zu 15 
Stellen, wahrend Dezimalzahlen bis zu 16 Stellen enthalten (15 
+ 1 fur den Dezimalpunkt ) . Positiven Zahlen mui^ kein Pluszeichen 
voranstehen, aber negativen GroSen muS ein Minuszeichen voran- 
stehen. 

Ze iclienl i ter al e 

Ein Zeichenliteral ist ein ' (einzelnes Hochkorama) , gefolgt von 
-null bis 50 Zeichen (andere als •), gefolgt von einem Das 
folgende sind gultige Zeichenliterale . 

'Dies ist eine gultige Zeichenkonstante ' 
'ZYZZY und PLUGH sind magische Worte ' 

Das letzte Beispiel ist eine Null-Reihe. Falls es notwendig ist, 
ein einzelnes Hochkomnaazeichen in das Literal selbst einzu- 
bringen, kann der ubliche Trick der verwendung von zwei aufein- 
ander folgenden einzelnen Hochkommata angewendet werden. Zum 
Beispiel sind gleich 

'Mike' 's computer is broken.' und 

Mike's computer is broken. 

Es ist anzumerken, daS einzelne Hochkommata veirwendet werden 
mussen. Doppelte Anf uhrungsstriche sind nicht gultig. 

Sets und Synsbole 

Ein Set ist eine Zusammenstellung von DatengroEen konstanten 
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werts Alle Konstanten sind vom selben Datentyp. Zum Beispiel 
sind alle CHAR (6) oder alle sind SMALLINT. Aufgrund dxeser 
Eigenschaft konnen wir auf den Datentyp eines Sets Bezug nehtnen. 
Die Konstanten eines Sets verhalten sich wie Felder und nicht 
wie Views in folgendem Sinne: 

Sie konnen nicht in niedrige Levels . auf gebrochen werden 
und 

sie konnen keirie Auf trittshauf igkeitsklausel aufweisen, 

zusatzlich kann der gesamte Set keine Auf trittshauf ig 
keitsklausel haben. 

Beispiel : 

SET ' MONTHSET SMALLINT, 

JAN VALUE 1, 

FEB VALUE 2, 

MAR VALUE 3, 

APR VALUE 4, 

MAY VALUE 5, . 

JUN VALUE 6, 

JUL VALUE 7 , 

AUG VALUE 8, 

SEP VALUE 9, 

OCT VALUE 10, 

NOV VALUE 11, 

DEC VALUE 12; 

Das Beispiel definiert einen MONTHSET genannten Set, der aus 
einer Sanimlung von zwolf Konstanten zusammengesetzt ist, die dxe . 
zwolf Monate eines Jahres wiedergeben. Ihre Symbole sind JAN, 
FEB, . . . DEC, und ihre zugeordneten Werte sind ganzzahlige 
Literale 1, 2, 12. ^ 

MONTHSET i St vom Typ SMALLINT, was bedeutet, daS das Format der 
Werte SMALLINT ist. Es kann keinen VALUE 3.21 und kemen VALUE 
"NOT AN SMALLINT" und keinen VALUE 1234565 geben. (Das letzte 
Beispiel ist ungultig, weil ein SMALLINT nicht die Zahl 32767 
uberschreiten kann.) 

Dieses Beispiel wird fur weitere Erlauerungen des Setkonzepts 
verwendet werden. 

Jede der Konstanten eines Sets besitzt eine Bezeichnung, genannt 
ein SYMBOL, und einen Wert. Das SYMBOL ist ein Hilfsmittel zur 
Bezugnahme auf den zugrundeliegenden Wert. Ein Setsymbol kann in 
derselben Weise verwendet werden wie ein. Feld. Der grund- 
satzliche unterschied ist, daS der Wert eines Setsytnbols 
konstant ist und niemals durch eine Regelanweisung geandert 
werden kann, wahrend der Wert eines Felds geandert werden kann; 
z. B. durch Loschen oder indem das Feld zum ziel einer MAP- pder 
OVERLAY "Anwei sung gemacht wird. 

Angenommen SYMXXX ist ein Symbol, das zu einem Set SETYYY 
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gehort. Dann kann auf das Syinbol auf eine der folgenden Weisen 
Bezug genommen werden: 

S.YMXXX 

SYMXXX IN SETYYY 

Das IN-Schlusselwort wurde anstelle des OF-Schlvisselworts 
gewahlt, um eine Uberf rachtung der Bedeutung des letzteren bei 
zu vielen unterschiedlichen Verwendungen zu vermeiden. SYMXX tny£ 
durch seinen Set qualifiziert werden, falls SYMXX in der Regel 
verwendet wird, entweder als Symbol eines anderen Sets Oder als 
ein Feldname oder als ein viewiiame. 

Ruckbezugnehmend auf das MONTHSET-Beispiel : 

^4AR 

MAR IN MONTHSET 
3 

beachte, daS alle exakt dieselbe Bedeutiing haben, namlich die 
Zahl 3. 

MAP FEB IN MONTHSET TO XXXVAR OF YYYVIEW 

hat den Ef fekt des verschiebens des Werts 2 in das Feld XXXVAR, 
das hoffentlich irgendwo innerhalb der Regel oder seines 
Verbindungspf eils richtig als numerisches unterfeld des view 
YYYVIEW erklart wurde. 

Innerhalb eines Sets kann es nicht zwei oder raehr Syrobole mit 
demselben Symbolriamen geben. Es ist aber anzumerken, daS ein Set 
verschiedene Synibole mit einem und demselben Wert besitzen kanni 

Andere Bezeichnxmgen 

Neben Datengr66en werden die folgenden Elemente in einer Regel 
verwendet : 

. Regelname 
. Komponentenname 
. Fenstername 
. Setname 

Sie werden im Detail wahrend der Diskussion der ausfuhrbaren 
Anweisungen beschrieben werden, wo sie auftreten. 

Lokale Erklarungen 

Gelegentlich ist es bequem, lokal Variablen in einem Regel - 
progratran zu haben. Eine Variable, die als indizierende Variable 
eines indizierten DO verwendet wird, ist ein gates Beispiel fur 
eine solche Variable. Die DCL . . . ENDDCL-Anweisung ermoglicht die 
Erklarung von lokalen Variablen. 
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Syntax 

Die DCL 



ENDDCL-Anweisung hat die Form: 



DCL 

Erklarung; [Erklarung; . . . ] 
ENDDCL , 

wobei die Erklarung entweder 

[Bezeichnung [ (S) ] 
[, Bezeichnung [ (S) ] , Erklarungs_Typ 

Oder 

. EXTERNe Bezeichnung 

[, Bezeichnung, ..-] SET 

ist, wobei " (S) " ein Tief index (ganzzahlige Kostante in 
Klatnmern) ist. 

Der Erklainingstyp ist einer der folgenden: 

SMAIiLINT 

INTEGER 

CHAR 

LIKE bereits_erklarte__Datengr6fie 
Axunerkuiig : 

Erklarungen des Typs EXTERN konnen nicht tief indiziert 
weirden. "Bezeichnung" mu6 mit einem alphabetischen Zeichen 
beginnen. Die folgenden zeichen sind entweder alphabetisch, 
numerisch oder Unterstriche . Bereits_erklarte_Datengr6Se 
bezieht sich auf eine GroSe, die der Regel bereits durch 
eine Vorbereitung von dem HPS-Endlager oder durch erne 
zuvorige lokale Erklarung bekannt ist. 



Ein Beispiel f olgt : 



DCL 



I, J, K, L, M, NM 
SSN 

TEMP_ID 
TEiyiP_VIEW 
ENDDCL 

Fig. 10 Beispiel einer DCL 



INTEGER ; 

CHAR (11) ; 

CHAR(#@) ; 

LIKE RTAXCMPI (5) ; 



ENDD CL - An we i s xmg 



Es ist anzumerken, daS es nicht moglich ist, einen Vxew dxrekt 
innerhalb einer DCL . . . ENDDCL-Anweisung zu definieren. Es ist 
moglich, so etwas indirekt mit der LIKE-Klausel zu tun. In dem 
obigen Beispiel ist TEMP^VIEW ein zeitweiliger lokaler view mit 
nahezu derselben Struktur wie RTAXCMPI. Der einzige unterschied 
ist, daS der Ol-Levelname TEMP_VIEW ans telle von RTAXCMPI ist 
und'dafi TEMP VIEW 5-mal auftritt. 
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ANHAN6 D: Ausffihrbare Anweisungen der Regelspraclie 



Zuoarctoimg von We r ten 

Drei Arten von Anweisungen andern die Werte von Daten, die in 
Feldern und Views enthalten sind: IVIAP, CLEAR und OVERLAY. Die 
Syntax und Semantik jeder der Anweisungen wird in der Folge 
beschrieben werden. 

MAP - ANWEl SUNG 

Syntax 

Die Syntax der MAP-Anweisung ist : 

MAP Daten_Gr6Ee TO Variable, 

wobei Daten_Gr6Ee eine Konstante, ein Feidname oder ein viewname 
und Variable entweder ein Feidname oder ein View-Name ist. Man 
erinnere, daS die Feld- oder viewnamen unzweideutig (jualif iziert 
sein mussen , und dafi diese Namen Tiefindizes aufweisen konnen. 

Einige Beispiele folgen: 

MAP 'Syntax' TO CG_CHAR OF CG_VW_11 

MAP CG_CHAR OF CG_VW_11 TO CG_CH7VR OF SUB__VIEW OF 
CG_VW_13 (3) 

MAP 23400.00 TO CUST_BAL_AMT 

Fig. 1 Beispiel von KAP-Anweisungen 



Semantik 

Das Resultat der Abbildung z. B. von A auf B kann in Abhangig- 
keit von den Datentypen von A und B stark variieren. Wie jene 
Zuordnungen arbeiten, kann man durch Studieren der folgenden 
Matrize sehen, die gemaB dem folgenden Prinzip aufgebaut ist: 

Die mogliche Quellen (A) fur eine MAP-Anweisung bildet die 
Zeilen der Matrix, und die moglichen Bestimmungen (B) bilden 
ihre Spalten. Die Richtigkeit der Syntax bzw. das Ergebnis der 
MAP-Operation wird am Sclmittpunkt der Reihe und Zeile gegeben. 
Die Zahlen in Klaramern bezieben sich auf die nuraerierten Para- 
graphen, die der Matrize unmittelbar folgen. VW(5) und VW(8) 
sind zwei Views beide mit mehrfachen Auftritten, aber einer 
mit weniger (5) und der andere mit mehr (8) . 



i 
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Quelle 


(B) 


Bestinimung 






View 


Feld 


Konstante 


VW (5) 


VW(8) 


V -L. W 


OK 
(1) 


FEHLER 


FEHLER 


WARNUNG 
(3) 


WARNUNG 
(3) 




FEHLiER 


f /L\ 




FEHLER 


FEHLER 


JNLLlUcX. . 

Literal 


f CiXxi mix. 


f ^-X 

v6; 




FEHLER 


FEHLER 


Zeichen- 
literal 


FEHLER 


(5) 


FEHLER 


FEHLER 


FEHLER 


Set 


FEHLER 
(2) 


FEHLER 


FEHLER 


FEHLER 


FEHLER 


Symbol 


FEHLER 


(6) 


FEHLER 


FEHLER 


FEHLER 


VW{5) 


WARNUNG 


FEHLER 


FEHLER 


OK 


WARNUNG 


VW(8) 


WARNUNG 
(3) 


FEHLER 


FEHLER 


WARNUNG 
(3) 


OK 



Fig« 2 Die KAP-Operation 



(1) Das Abbilden eines Views auf einem view bedeutet das Abbil- 
den aller Unter-Views und/oder Felder mit entsprechenden 
Namen, die dem Quell-View und detn Bestirtmungs-View unter- 
geordnet sind. Zum Beispiel angerioiratien^ man hat: 



VIEW_1 

ABC 

DEF tritt auf 

OPQ 

XXX 

BBB 

XXY 

XYZ 



VIEW_2 

OPQ 

(50) ABC 

DEF tritt auf 
BBB 

zzz 



(9) 



wobei die Spezif ikationen der Unter-Views und der Felder 
von VIEW_1 und VIEW__2 unerlieblicli sind. Dann hat MAP VIEW_1 
TO VIEW_2 den folgenden Effekt: 



ABC 


OF 


VIEW 


1 




wird 


verschoben 


nach 


ABC OF VIEW_ 


2 


OPQ 


OF 


VIEW 


1 




wird 


verschoben 


nach 


OPQ OF VIEW 


2 


BBB 


OF 


VIEW 


1 




wird 


verschoben 


nach 


BBB OF VIEW 


2 


DEF 


OF 


VIEW 


1 


(1) 


wird verschoben 


nach 


DEF OF VIEW 2 


(1) 


DEF 


OF 


VIEW 


1 


(2) 


wird 


verschoben 


nach 


DEF OF VIEW 2 


(2) 


DEF 


OF 


VIEW_ 


1 


(5) 


wird 


verschoben 


nach 


DEF OF VIEW 2 


(5) 



i m « • 



• • • 
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Azunerkungen : 

Nichts wird von xxx, xxy, xyz irgendwo hin abgebildet, weil 
VIEW_2 keine direkten Nachfolger mit diesen Namen unter 
sich hat. Nichts wird auf zzz aibgebildet, weil VIEW_1 
keinen Nachfolger mit diesem Namen direkt unter sich hat . 

Angenommen, daS xxx und zzz ihrerseits Views sind, die wie 
folgt aufgebaut sind: 

XXX zzz 
FTiDl FLDl 

FLD2 FLD3 

FLD3 FLDS 

dann wird 

FLDl OF xxx OF VIEW_1 nicht nach FLDl OF zzz OF VIEW__2 
verschoben und 

FLD3 OF xxx OF VIEW_1 nicht nach FLD3 OF zzz OF VIEW_2 
verschoben . 

Der Grund ist, dafi nur die Nachfolger direkt unter der 
Quelle (= VIEWED und dem Ziel (= VIEW_2) der MAP-Anweisung 
in Frage kommende Kandidaten fur ubereinstimmende Namen 
sind. Das heil^t, der Codeerzeuger schaut nur ein Level 
abwarts, wenn er vergleiche der view-Strukturen durchfuhrt. 

(2) Ein Set ist weder eine Konstante npch eine Variable, . und 
absolut nichts kann von einem Oder auf einen Set abgebildet 
werden . 

(3) Angenommen, daS A nn-mal auftritt und B mm-mal auftritt und 
dafi min die kleinere Zahl von mm und nn bezeichnet, dann 
bedeutet : 

MAP A TO B 

genau dasselbe wie das folgende Regelf ragment : 

DO FROM 1 TO min INDEX IX 

MAP A(IX) To B(IX) 

ENDDO 

Falls entweder A mehrmals auftritt und B nicht oder A 
einmal auftritt und B mehrmals, dann ist MAP A TO B 
entweder Equivalent zu 

MAP A (1) TO B 

Oder 



MAP A TO B(l) 




72 



(4) Siehe die Feld-zu-Feld Abbildung Fig. 2. Ein Quell-Literal 
des Typs INTEGER Oder DECIMAL beniTtimt sicti genau so. wie 
eine Variabel dieses Typs . 

(5) Siehe die Feld-zu-Feld Abbildung in Fig. 2. Ein Quell- 
Literal der Form 'ABCDEFGH* benitrant sich genau so wxe erne 
variable des Typs CHAR (8) . 

(6) Siehe die Feld-zu-Feld Abbildung in Fig. 2. Eine Quelle, 
die ein Symbol ist, das zu einem Set eines gegebenen Typs 
gehort, benimmt sich genau so wie eine Variabel desselben 
Typs . 



Abbilden von VARCHAR-Feldem 

im folgenden ist beschrieben, wie MAP-Anweisungen mit Variablen 
des Typs VARCHAR arbeiten. 

Der Hauptunterschied zwischen Variablen des Typs VARCHAR (nn) 
und jenen des Typs CHAR (nn) beruht auf der Tatsachei, daS 
VARCHAR (nn) -Variablen ein zugeordnetes Langenf eld haben, 
genannt xxx LEN fur eine VARCHAR-Variable xxx. xxx_LBN enthalt 
die "aktuelle Lange" von xxx, wahrend nn die "maximale Lange" 
von xxx ist. 

Angenommen, daS B eine Variable des Typs VARCHAR mit eiher Lange 
B LEN ist, und daS A eine Variable, ein Literal, ein Symbol des 
lyps VARCHAR Oder vom Typ "CHAR" ist- Dann wird B_LEN von der 
Lange von A in einer MAP-Anweisung A TO B wie folgt festgelegt. 

Falls die Lange von A <= die maximale Lange von B ist, 
dann : 

B LEN = Lange von A 

Inhalte von B = Inhalte von A aufgefullt mit Leer- 
zeichen nach rechts 

Falls die Lange von A > die maximale Lange von B ist, dann: 
B LEN = maximale Lange von B 

Inhalte von B = die ersten "maximale Lange von B" 
Zeichen von A 

Beispiele der Verwendung von VARCHAR-Variablen 
Angenommen, daS wie folgt: 

CHARIVARI vom Typ CHAR (10) 

CHAR_VAR2 VOm Typ CHAR (20) 

VARCH^VARl vom Typ VARCHAR (15) 

VARCH VAR2 vom Typ VARCHAR (20) 



Weiter angenommen, dafi man eine Regel hat, die aus den folgenden 
Abbildungsanweisungen besteht : 



1. 


MAP 


•ABC 


2 . 


MAP 


'**MSINE IiANGE 1ST 20** 


3 . 


MAP 


•ABC 


4 . 


MAP 


CHAR VAR 1 


5 . 


MAP 


CHAR VAR__2 


6 . 


MAP 


CHAR VAR 2 


7 . 


MAP 


VARCH VAR_2 


8 . 


MAP 


VARCH VAR_1 
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TO CHAR_VAR_1 
TO CHAR_yAR_2 
TO VARCH_VAR_1 
TO VARCH_VAR_1 
TO VARCH_VAR_1 
TO VARCH_VAR_2 
TO VARCH_VAR_2 
TO VARCH_VAR_2 

Darin wird das folgende Ergebnis bei den VARCHAR-Variablen 
auf treten 

#1 und 2 Nichts wurde bislang VARCH_VAR_1_LEN und 
varch_var_2__IjEN zugeordnet, 

#3 VARCH_VAR_1_LEN = 5 = Lange von 'ABC 

#4 VARCH_VAR_1_LEN =10 = Lange von CHAR__VAR_1, 

VARCH VAR 1 LEN = 15 = Lange von VARCH_VAR_1, ^der 
inhalt von VARCH_VAR_1 wird sein '**MEINE LANGE 
IS 

4*6 VARCH VAR 2 LEN = 20 = Lange von VARCH_VAR_2 , der 

Inhalt von VARCH_VAR_2 wird sein •**MEINE LANGE 
1ST 20** • 

4£7 VARCH VAR 2 LEN = 20 = Lange von VARCH__VAR_2 , ^der 

Inhalt von VARCH_VAR_2 wird sein •**MEINE LANGE 
1ST 20** ' 

4*8 VARCH VAR 2 LEN = 15 = Lange von VARCH_VAR_1 , ^ der 

inhalt von VARCH_VAR_2 werden sein •**MEINE LANGE 
I • 

CLEAR - Anwe i sung 

Die CLEAR-Anweisung setzt numerische Felder auf Null und 
Zeichenf elder auf leer. 

Syntax 

Die CLEAR-Anweisung hat die Form: 

CLEAR Variable, 

wobei '-Variable" der voile oder teilweise qualif izierte Name 
entSeder eines Views oder eines Felds ist . Falls ^-^.^J^^^^J^ 
werdende Variable Tiefindizes aufweist das J^exj^^^ ^^aS 
irgendwelche ihrer Views oder Sub- Views mehrfach auf treten, dann 
konnen auch Tiefindizes erscheinen. Zum Bexspiel setzt 

CLEAR VW_1 

alle numerischen Felder von VW_1 auf Null und leert die 
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Zeichenfelder . Man erinnere, daS numerische Felder INTEGER (n) , 
DECIMAL (p, q) und Felder, die mit PIC-Elementen 9 und V 

beschrieben sind, einschliefien. Zeichenfelder schlieSen CHAR (n) 
und VARCHAR (n) ein. 

Semantik 

Ein Feld des zugrundeliegenden Typs "Zeichen" (nicht ein- 
schlieSend PiCs) wird auf Leerzeichen gesetzt. Ein Feld des 
zugrundeliegenden Typs "numerisch" (einschlieSlicb Dezimalzahlen 
und PICs) wird auf null gesetzt. 

Ein view, sagen wir V, wird wie folgt behandelt: 

(1) AngenoTTimen, dafi V Felder besitzt, aber keinen view, dann 
wird jedes dieser Felder . auf Leerzeichen oder null gesetzt, 
abhangig davon, ob seiti zugrundeliegender Typ "Zeichen" oder 
"numerisch" ist. Falls v ein view ist, der mit Tiefindizes 
versehen ist (die entsprechende OCCURS-Klausel konnte 
moglicherweise auf einem hoheren Level als demjenigen von V 
f estgelegt sein) , dann bedeutet das Loschen von V dasselbe wie 
das Loschen von jedem V(S1) oder V(S1, S2) oder v(si, S2 , S3). 
Dabei bezeichnen Si, S2 und S3 die Tiefindizes von V und hangen 
von der Anzahl der daruber stehenden OCCURS ab; das Loschen 
schlieSt den Level von V ein, unabhangig davon, ob V einmal, 
zweimal oder dreimal tief indiziert ist. 

(2) Falls V einen oder mehrere Views VI, V2, ... als Nachfolger 
hat, dann behandele V wie folgt: Losche die Felder, die die 
Nachfolger von V sind, genau wie es oben dargelegt wurde. Dann 
Priife jedes VI, V2, urn f estzustellen, ob es auch Felder als 
Nachfolger enthalt, und falls ja, behandele sie gemaS oben (1) . 
Anderenfalls liberprufe jeden Unter-view. 

Das Netz, das aus dem obigen Algorithmus resultiert, ist. wie 
folgt. Jeder View wird letztlich in einen Set von Feldem 
aufgeteilt. Jedes dieser Felder wird zu Leerzeichen oder auf 
null gesetzt, abhangig davon, ob sein zugrundeliegender Typ 
"Zeichen" oder "numerisch" ist. 



OVERLAY- Anwei sung 

Diese Anweisung wird verwendet, um eine Struktur in einem 
Speicher durch den Inhalt einer anderen zii ersetzen ("uber- 
decken" ) . 

Syntax 

Die OVERLAY -Anweisung hat die Form 

OVERLAY DatengroSe TO Variable, 




wobei Datengrofie eine Konstante, ein Feld oder ein View ist, und 
Variable entweder der Name eines views oder eines Felds ist. 



Wie in deiu Fall der MAP -Anwei sung ist die Auswirkung von OVERIiAY 
komplex und hangt von den Typen der Quell- und Bestiiranungs- 
variablen ab. 
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Fig. 3 Die OVSRIiAY-Qperation 



(la) Die OVERLAY -Anwei sung arbeitet auf eine fundamental andere 
weise als die MAP-Anweisung . Falls die Quell- und Bestim- 
mungs (D) -Variablen beides Views sind, dann hat OVERLAY S TO 
D denselben Effekt wie eine gerade COBOL - Ver s chi ebung . 
Sowohl S als aucli D warden behandelt, als seien sie vom Typ 
Zeichen (Character) . nn sei die kleinere Lange von Lange(S) 
und Lange (D) , dann wird die obige Anweisung einf ach die am 
weitesten links stehenden n Zeichen vom S in die am 
weitesten links stehenden nn Zeichen von D uberfuhren, 
wobei die iiberschussigen Bytes von D mit Leerzeichen 
aufgefiillt werden, falls Lange (D) groSer ist als Lange (S). 

(lb) Falls A ein view und B ein Feld ist, dann ist OVERLAY A TO 
B OK, solange wie B vom Typ "Zeichen" ist (was bei einem 
PIC-Feld der Fall ist) . 

(ic) Entweder A oder B oder beide miissen ein view sein. Eine 
Konstante kann mit uberhaupt nichts uberdeckt werden. 
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(2) Bin Set ist weder eine Konstante noch eine Variable, und 
nichts kann von einem Set uberdeckt werden Oder eirien Set 
uberdecken. 

(3) Angenommen, dafi A nn-mal auftritt und B mm-mal auftritt und 
daS min den kleineren Wert von mm und nn bezeichnet, dann 
bedeutet 

OVERLAY A TO B ■ 

genau dasselbe wie das folgende Regelf ragment : 

DO FROM 1 TO min INDEX IX 

OVERLAY A (IX) TO B(IX) 

ENDO 

Falls entweder A mehrfach auftritt und B nicht oder A 
einmal auftritt und B mehrfach, dann ist OVERLAY A TO B 
entweder Equivalent zu 

OVERLAY A{1) TO B 

Oder 

OVERLAY A TO B(l) 

(4) Es ist erlaubt, ein Feld mit einem View oder umgekehrt zu 
uberdecken, so lange das Feld vom Typ "Zeichen" ist. Der 
Grund ist, dafi Views selbst kls vom Typ "Zexchen" ange- 
noramen werden ( COBOL -Konvent ion) . 

(5) Es ist erlaubt, einen view mit einer Konstanten (Literal 
Oder Symbol) zu uberdecken, solange die Konstante vom Typ 
"Zeichen" ist. 



ANHANG E: SteuerfluE bei einer Kegel 

Die Regelsprache verwendet die ublichen Steuerf luSkonstnikte : IF 
und IF ... ELSE fur Bedingungsausf iihrungen, CASEOF fur die 
AuswatLl von einer von mehreren Altemativen und DO . . . WHILE fur 
die Steuerung von wiederholten Schleifen. 

Bedingungen 

Eine Bedingung ist eine Mischung von Datengrofien, Verhaltnis- 
operatoren, Boole 'schen Operatoren und Klarnmern. Eine DatengroBe 
umfaEt Zeiclien-, ganzzahlige und dezimale Konstanten, Felder und 
Views. Die Verhaltnisoperatoren und Boole 'schen Operatoren sind: 



• Operator Bedeutung 



gleich . 

<> nicht gleich 

< weniger als 

<= weniger als oder gleich 

> groSer als 

>= groSer als oder gleich 

INSET ist enthalten in 

AND ^ Konjunktion 

OR Adjunktion 

NOT Verne inung 



Fig. 1 Verhaltnisoperatoren und Boole 'sche Operatoren 

Die Bedingung ist entweder eine einmalige Verhaltnisbedingung 
(im folgenden eine "einfache Bedingung" genannt) oder zwei Oder 
mehrere einfache Bedingungen, die durch die Boole • schen Opera- 
toren verbunden sind. Eine einfache Bedingung hat die Form 

DatengroSe Verhaltnisoperator DatengroSe 

Einige Beispiele sind: 

CUST_BAL_AMT < 10 00 

GROSS_PAy OF RTAXCMPI >= FICA_CUTOFF 
CUSTOMER_ID <> •1134-4* 
12 INSET MONTH_OF_YEARS 

Die Regelsprache fuhrt eine Datentypuberpriifung durch; Ver- 
gleiche konnen nur zwischen DatengroEen vom gleichen Typ 
durchgefuhrt werden zahlen mit Zahlen und Zeichen mit 

Zeichen. Alle diese Vergleiche der GroEe sind bei numerischen 
Daten verfiigbar, aber nur Tests auf Gleichheit oder Ungleichheit 
sind bei Zeichen-Daten erlaubt . 



Jede einfache Bedingung resultiert in einen Wert von entweder 
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* >Ergebni s se=FALSE<* 

* >Ergebni s s e=TRUE < * 
*>Ergebnisse=FALSE<* 
* > E rgebni s s e = TRUE < * 
*>Ergebnisse=TRUE<* 
*>Ergebnisse=FALSE<* 

SHRTINT INSET NAMESET 
LONGINT INSET MONTHSET 

Naturlich kann zum Zeitpunkt der Codeerzeugung nichts uber die 
Ergebnisse der beiden letzten Ausdrficke gesagt werden, weil sie 
Variablen involvieren. Es mag den Leser uberrascht haben, dafi: 

JAN IN NAMESET INSET MONTHSET das Ergebnis FALSCH ergibt . 

Ein Vergleich von gleichen Typen wird streng durchgefuhrt . 
vergleiche zwischen numerischen Daten und nicht- numerischen sind 
immer Fehler. Die folgende Tabelle gibt Bedingungen wieder, dxe 
beim Vergleich von zwei Zeichentypen oder zwei numerischen Typen 
auftreten konnen. Die Bedeutung der Anmerkung (1) variiert 
jedoch gemaS den verglichenen Typen. 



Erste (s) 


Zweite (s) 


Literal 


Setsymbol 


Variable 


Literal 


Fehler 


Warnung . 


(1) 


Setsymbol 


Wamung 


Warnung 


(1) 


Variable 


(1) 


(1) 


OK 



Pig. 3 Fehlerbedingungen beim vergleich 
von Zeichen und numerischen Grdfien 

(1) Der Vergleich einer Zeichenkonstante mit einer Zeichen- 
variablen ist erlaubt, solange die Lange der Konstanten 
kleiner oder gleich der maximalen Lange der Variablen ist . 
Anderenfalls wird ein Syntaxfehler erzeugt. 

Es ist ein Fehler, ein groSes (im absoluten Wert) nume- 
rische Literal mit einer Variablen zu vergleichen, die "zu 
klein" ist,. um einen so grol^en Wert aufzunehmen. Zum Bei- 
spiel kann ein SMALLINT-Feld Werte von -32,768 bis +32,767 
aufnehmen. SMALL_INT sei ein SMALLINT-Feld. Der folgende 
Vergleich wird vom Regelcodeerzeuger nicht erlaubt : 

SMALL_INT > 100 0000 

Auch subtilere Fehler werden aufgezeigt. POS-NUMBER sei eine 
Dezimalzahl, die von dem Bild "PIC 9999/V99" in dem HPS-Endlager 



Sind die folgenden Ausdrucke gultig: 

JAN IN MONTHSET INSET NAMESET 
AL INSET NAMESET 
AL <= JAN IN MONTHSET 
Aii <= JAN IN NAMESET 
AL <= AL IN NAMESET 
AL <= AL NAMESET 
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beschrieben wird. Dann ist die nachste Beispielbedingung auch 
nicht erlaiibt: 

POS_NUMBER < 0 . 

Dies ist ein Fehler, weil POS_NUMBER kein fxihrendes Vorzeichen- 
bildelement S hat. 

Anmerkung: . ^ ^ „ 

Angenotranen bei dem Vergleich von ZeichentypgroSen sei X = 
'ABC und Y = »ABC* und Z = 'ABC dann smd X, Y und Z 

samtlicli aquivalent, soweit eine Uberprufung auf Gleichheit 
betrof f en ist . 

Mit anderen Worten ergeben die komplexen Bedingungen X = Y 
und Y = Z und X = Z den Wert TRUE. Anzutnerken ist wexter- 
hin, daS die zugehorige ASCIl-Sequenz und nicht die 
zugehorige EBCDIC- Sequenz bei einetn relativen Vergleich 
zahlt. Bei der oben gegebenen Definition ergibt die Bedin- 
gung 

X >= 'IBC 

das Ergebnis TRUE, weil der ASCII-Wert von '1' 49 ist, 
wahrend der ASCII -Wert von 'A' 65 ist. 



IF - Anweisung 

IF . . . , IF ... ELSE (Bedingte Ausfuhrung) 
Syntax 

Die IF-Anweisung hat die grundsatzliche Form 

IF Bedingung 

Anweisung . . . 



[ELSE 

Anweisung . . . ] 



ENDIF 



wobei "Bedingung" eifi logischer Ausdruck ist, der entweder TRUE 
Oder FALSE sein kann. "Anweisung" gibt eine Regelsprachenanwei- 
sung wieder und "..." bedeutet , daS die direkt vorangehende 
GroEe wiederholt werden kann, und [] impliziert, daS was inner- 
halb [ und ] enthalten ist, optional ist. Ein THEN xst m emer 
IF-Anweisung nicht erlaubt. 



CASEOF - Anwe i sxing 

CASE (Auswahl von einer oder mehreren Alternativen) 

Die CASEOF-Anweisung wahlt auf der Basis des Werts eines 
zeichenfelds oder eines numerischen Felds einen von mehreren 
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TRUE Oder FALSE. Zwei dieser Werte konnen mit den Boole • sctien 
Operatoren AND und OR kotrODiniert warden, und der Sxnn von einem 
von ihnen kann mit einem NOT umgekehrt werden. 

Zum Beispiel ist 

CUSTOMER_ID <> •1134-4' AND GROSS_PAY >= FICA_LIMIT 

TRUE, falls sowohl CUSTOMER_lD nicht gleich ist mit 13-23-4 • und 
GROSS PAY grofier oder gleich FICA_LIMIT ist; 

die Bedincmnq FALSE. Es wird angenornmen, daS customer_id 
eitwedSr VARCHAR oder ein View ist und daS GROSS PAY und 

PICA LIMIT INTEGER, DECIMAL Oder mit numerischen PiC-Elementen 
beschrieben sind. weiterhin raussen, damit diese Bedingung Sinn 
macht, die Beziehungsoperatoren <> und >= angewendet werden, 
bevor die beiden result ierenden werte mit dem AND zusammengefugt 
werden Dies schlieSt ein, daS alle Operatoren eine Hierarchie 
ihrel vorrangs haben. Die ubliche Hierarchie wird verwendet und 
ist in der folgenden Tabelle wiedergegeben . 

Operator Vorrang 

INSET hochster 

=y <>, <, <=, >, >= 

NOT 

AND 

OR nxedrigster 

Fig. 2 Vorrang - Bezieliujigsoperatoren und Boole -sclie 
operatoren 

Das Konzept des Vorrangs der Operatoren ist von der taglichen 
verwendung arithmetischer Berechnungen gut bekannt, wobex 
MSl^iSlikltion und Division vor Addition und Subtraktion ausge- 
fShr^ warden. In derselben Weise wird ein Test auf Unglexchhext 
iSs^efShrt? bevor zwei Bedingungen durch ein AND verbunden 
werden, was seinerseits getan wird. bevor xrgendwelche Bedxn- 
gungen durch ein OR verbunden werden. 

Klammern konnen verwendet werden, urn den Vorrang der operatoren 
zu uberstimmen. Zum Beispiel ist 

NOT X = Y OR C > D Equivalent mit (NOT X+Y) OR (C>D) , 
was seinerseits Equivalent ist mit X <> Y OR C > D. 



Jedoch ist 

NOT (X = Y OR C > D) Equivalent mit X <> Y AND C <= D . 

(weil es in der Regel TRUE ist. daS NOT (X OR Y) dasselbe , ist 
wie (NOT X) AND (NOT Y) . 

Die Beseitigung des NOT zeigt, daS die zwei Bedingungen recht 
unterschiedlich sind. So lange wie die Vergleiche zulassxg sxnd 
konnen die Bedingungen willkxirlich komplex werden. Zum Bexspxel 



m 
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ist 

((PAY > LIMIT OR BONUS >= MAX) AND ID <>'112A-3x') OR 

ID = • • 

syntaktisch korrekt . 
INSET-Anweisimg 

Ein Set kann daraufhin uberpruft warden, ob eine gegebene 
variable Oder Konstante als Wert iimerhalb des Sets auftritt. 

X sei eine Datengrofie, deren Datentyp mit dem Datentyp des Sets 
kompatibel ist (selbst weiin sie nicht notwendigerweise mit 
diesem identisch ist) . 

Dann ist 

X INSET SET_NAME 

eine Bedingung, die TRUE Oder FALSE in Abhangigkeit davon 
ergibt, ob Oder ob nicht mindestens einer der Werte in SET_NAME 
den Wert von X trifft. 

Es ist nicht erlaxibt zu prufen, ob eine numerische DatengroSe 
innerhalb eines Sets vom Typ Zeichen enthalten xst Oder 
umgekehrt. Es ist anzumerken, daS PIC-Felder und/oder Setsyrnbole 
sowohl mit Zeichen- als auch nutnerischen Datengrofien verglichen 
werden konnen. Es ist auch anzumerken, daS bei exnetn Vxew fur 
Vergleichszwecke angenoiranen wird, dafi er sich wie eine Zeichen- 
variable verhalt . 

Unter Annahme der folgeriden Erklarungen: 

CHRVARl CHAR (10) , 

CHRVAR2 CHAR (6) , 

SHRTINT SMALL INT; 

LONGINT INTEGER; 

SET MONTHSET SMALLINT 

JAN VALUE 1, 

FEB VALUE 2, 



DEC VALUE 12; 

SET NAMESET INTEGER 

AL VALUE 4 

JAN VALUE 123 45 

JAMES VALUE 1234567, 

JIM VALUE 12345677, 

JON VALUE 123456788 

BOB VALUE 123456789; 
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Alternativen Ausf uhrungswegen aus. Sie ist in ihrer Bedeutung 
melireren geschachtelten IF . . . ELSE-Anweisungen aquivalent. 

Syntax 

Die CASEOF-Anweisung hat die folgende Form: 
CASEOF Variable 

CASE Literal [Literal] . . , 
[Anweisung . . . ] 

[CASE Literal [Literal] ... 
[Anweisung ...]]... 

[CASE OTHER 

[Anweisung . . . ] 1 

ENDCASE 

Die hier veirwendete Notation, urn die Syntax auszudriiclcen, ist 
Icomplexer als diejenige, die fur die IF-Anweisung verwendet 
wurde. EcJcige Klanunem ([ und ]) sctilieSen Dinge ein, die 
weggelassen werden Iconnen. PunJcte (...) deuten an, daS dxe 
direkt voranstehende GroSe wiederholt werden kann. Das Zusaitimen- 
fassen dieser beiden Konventionen bedeutet, daE [Anweisung ...] 
aquivalent ist mit keine Anweisungen (alles innerhalb [ und ] 
ist optional) oder einer Anweisung, zwei Anweisungen (die einer 
Anweisung f olgenden . . . bedeuten, daS sie wiederholt werden 
kann) , drei Anweisungen usw. . 

Semantik 

Die CASEOF-Anweisung ist ein kurzerer Weg, urn denselben Steuer- 
fluS wie unter Verwendung verscliaclitelter IF . . . ELSE-Anweisun- 
gen auszudrucken. Die Variable wird mit der Liste der Lxterale 
verglichen, die dem ersten reservierten CASE-Wort folgen. Falls 
sie einem von diesen gleicht, dann werden die Anweisungen, die 
dem ersten CASE folgen, ausgefuhrt bis zu dera aber niclit ein- 
SchlieBlich des zweiten CASE; der SteuerfluS geht dann zu den 
Anweisungen uber, die dem ENDCASE folgen. 

Falls die Variable keinem der Literale gleicht, die der ersten 
CASE-Klausel folgen, dann wird sie mit.den Literalen vergliclien, 
die dem zweiten CASE folgen. Falls die Variable einem von diesen 
gleicht, dann werden die Anweisungen, die der zweiten CASE- 
Klausel folgen, bis zu dem aber niclit einschlieSlich des dritten 
CASE ausgefuhrt; der FluS geht dann zu den dem ENDCASE folgenden 
Anweisungen uber . 

Dieser ProzeS wird wiederholt, bis alle CASE-Klauseln verbraucht 
sind. Die dem optionalen CASE other folgenden Anweisungen werden 
nur ausgefuhrt, falls die Variable bei der CASEOF-Klausel keinem 
der Literale gleicht, die bei den CASE-Klauseln aufgefuhrt sind. 

Die Literale, die bei den verschiedenen CASE-Klauseln auftreten, 



83 



durfen nur einmal auftreten. Ein Literal, das in einer CASE- 
Klausel auftritt, kann nicht in einer anderen wiederholt warden. 

Im folgenden ist ein Skelettbei spiel der Verwendung eines 
CASEOF-Konstrukt s gezeigt zusammen mit der semantisch 
identischen Ubersetzung in einen Satz von verschachtelten IF- 
Anweisungen . 

CASE OF TRANS_CODE 

CASE 'A' 'C* 

Anweisung l 
Anweisung 2 

CASE 'M* 'R' 

Anweisung 3 

CASE 'X' 

Anweisung 4 
Anweisung 5 

CASE OTHER 

Anweisung 6 

ENDGASE 

Die dem obigen aquivalente IF-Anweisung f olgt : 

IF TRANS_CODE =. 'A» OR TRANS_CODE = 'C* 

Anweisung 1 
Anweisung 2 

ELSE 

IF TRANS_CODE = •M' OR TRANS_CODE « 'R« ' 
OR TRANS_CODE = 'U' 

Anweisung 3 

ELSE 

IF TRANS_CODE = 'X' 

Anweisung 4 
Anweisung 5 

ELSE 

Anweisung 6 

ENDIF 
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ENDIF 

ENDIF 

Zu bemerken ist, da& die CAS EOF-Anwei sung implizit Uberpruf ungen 
auf die Gleichheit zwischen einer Variablen (Feld oder View) und 
einer Konstanten verwendet. Die bei der IF-Anweisung durchge- 
f uhrten Typenuberpriif ung wird auch hier durchgef uhrt . Konstan- 
ten, die in den CT^SE-Klauseln auftreten, mussen denselben Typ 
wie die Variable haben, die bei der CASEOF-Klausel auftreten. 

DO - Anwe i sung 

Das DO ... ENDDO-Konstrukt stellt eine Steuerung von wieder- 
holten Schleifen bereit, und es gibt zwei Varianten eine mit 
einem expliziten Schleif enzahlmechanismus und eine ohne . 

Die Form der DO ... ENDDO-Schleif enkontrollstruktur ist wie 
folgt: 

. DO , . 

[Anweisung . . . ] 

WHILE Bedingung 
[Anweisung . . . ] 

ENDDO 

Die Form mit dem expliziten Schleif eiizalilmechanismus ist : 

DO [FROM ganzzahlige DatengroSe] 
[TO ganzzahlige DatengroSe] 
[BY ganzzahlige DatengroSe] 
[INDEX ganzzahlige Variable] 

[Anweisung . . . ] 

[WHILE Bedingung] 

[Anweisung . . . ] 

ENDDO 

Die "Bedingung", die in der WHILE-Klausel auftritt, ist vom 
selben Typ von Bedingung, wie oben im Abschnitt der IF-Anweisung 
beschrieben wurde. Eine "ganzzahlige Variable" ist ehtweder ein 
Feld, das als INTEGER in dem Endlager definiert ist, oder es ist 
eine lokale DCL (Erklarung) gegenuber der Regel . Eine "ganz- 
zahlige DatengroSe" ist ein Literal, eine Setkonstante oder der 
Name eines Felds, das als INTEGER definiert ist. Falls notig 
kann, urn irgendwelche Zweideutigkeiten zu losen, eine teilweise 
Qualif izierung und Tief indizierung bei den Feldnamen gefordert 
werden . 
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Einige Beispiele von DO-Schleifen folgen: 
DO 

. WHILE PICA OF RTAXCMPI <FICA_r470C__IN PARAMETERS 
Anweisung 1 
Anweisung 2 

ENDDO 
DO 

Anweisung 1 
Anweisung 2 

WHILE TOTAL_AMT_> TOTAL_LIMIT 
ENDDO 

DO TO LOOP_END BY STEP INDEX COUNTER OF RXYZZYI 
Anweisung 1 
Anweisung 2 

ENDDO 

DO FROM LEVEL OF RSTATUSI 
Anweisung l 
Anweisung 2 

WHILE CODES (LEVEL) <> TERM_CODE IN VALID_CODES 
ENDDO 
Semantik 

Bei dem ersten Typ von DO-Konstrukten ohne den expliziten 
Zahlimechanismus werden die Anweisungen zwischen DO und ENDDO 
in der Reihe ihres Auftretens wiederholt, solange die Bedingung 
in der Klausel TRUE ist . Wenn die Bedingung FALSE wird, geht die 
Steuerung von der WHILE-Klausel zu der Anweisung liber, die auf 
ENDDO folgt. Es ist anzumerken, <la& die WHILE-Klausel ara.Beginn 
der Schleife, am Ende der Schleife oder irgendwo in der Mitte 
der Schleife auftrefcen kann. 

Bei dem zweiten Typ von DO werden fur jede fehlende Klausel 
(FROM, TO, BY) Ersatzwerte bereitgestellt 1 Falls FROM weg- 
gelassen wird, beginnt die Schleif enzahlung bei l; falls TO 
weggelassen wird, ist die Zahlgrenze auf 32.767 festgesetzt; 
falls BY weggelassen wird, ist das Schleif eninkrement auf 1 
festgelegt. Bemerke, daS die INDEX-Klausel nicht erscheinen muS . 
Zumindest eine Angabe FROM, TO, BY oder INDEX muS fur das DO 
angegeben werden, damit es als ein indiziertes DO erkannt wird. 
AuJSerdem miissen die IN-, FROM-, TO- und BY-Werte keine ganz- 
zahligen Konstanten sein; ganzzahlige Felder sind auch erlaubt . 
Letztlich kann bei einem indizierten DO zusatzlich eine WHILE- 
Bedingung vorgesehen sein, und sie kann uberall innerhalb der 
Schleife auftreten. 
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ANHAN6 F; Ubergabe der Steuerung zwischen Regeln 

Eine Regel kann eine andere Regel oder eine Kotnponente aufrufen. 
Eine Komponente kann eine andere Komponente, aber keine Regel 
aufrufen . 

USE -Anwei sung 

Syntax 

Die USE -Regel -Anweisung ruft eine andere Regel auf, und die USE 
MODULE -Anwei sung ruft eine Komponente auf . Sie sind ahnlich im 
Erscheinungsbild : 

USE RULE Regel -Name [NEST] 
USE MODULE KoTt^onenten_Name, 

wobei Regel_Name der Name einer Regel uhd Koit^onenten_Name der 
Name einer Komponente ist, die dem Endlager bekannt sind. 

Semantlk 

Bei der Ausfuhrung von USE RULE oder USE MODULE wird die Steue- 
rung zu der benannten Regel oder Komponente uberfuhrt . Ungleich 
dem Fall von Programmierspractien sind der USE-Anweisung selbst 
keine der Parameter - zugeordnet, die zu der auf gerufenen Regel 
Oder Komponente zu iibertragen sind. 

Die Regelsprache erfordert, daS der Eingabe-View und der 
Ausgabe-view einer Regel in dem Endlager def iniert werden, nicht 
innerhalb des Programms selbst. Weiterhin muS der Eingabe-View, 
der zu der auf gerufenen Regel iibertragen wird, und der Ausgabe- 
view, der von ihr erhalten werden soli, in dem Endlager sowohl 
fur die aufrufende als auch fur die aufgerufene Regel yerzeich- 
net sein. 

Semantische Uberprufung der zielumgebungen 

In einem System, das die Architektur eines IBM-Mainframe eines 
IBM-Minicomputers, der das Stratus vos-Betriebssystem unter- 
stiitzt, und von PC-Arbeitsplatzen hat, kann nur eine Regel auf 
dem PC eine Regel, die zu einer abweichenden Zielumgebung 
gehort, aufrufen. Der Codeerzeuger wird einen Fehler anzeigen, 
falls man versuchen sollte, von einer Mainframe -Regel aus eine 
Stratus-Regel oder eine PC-Regel zu benutzen, oder falls man 
versuchen sollte, eine Mainframe -Regel oder eine PC-Regel von 
einer Regel auf dem Stratus aus zu benutzen. Es ist auch 
anzumerken, daS eine Regel nur eine Komponente benutzen kann, 
auf die in ihrer eigeneii Umgebung abgezielt wird. 

Semantische tXberpruf ungen <|er NEST-Klausel 

Die NEST-Option zeigt an, daE alle von dieser Regel aufgerufenen 
Fenster und ihre aufrufenden Regeln in einen Anzeigemodus 
gelangen; das heiSt, daS sie auf dem Schirm angezeigt werden, 



der zuvor umgewaridelt wurde. NEST kann nur verwendet werden, 
falls 

. die zielumgebung der benutzenden Kegel der PC ist oder 

. die Zielumgebung der benutzten Regel der PC ist. 

Regeln auf anderen Maschinen konnen jedoch keine Regel auf dem 
PC auf rufen (aufier indirekt durch die ASYNC-Einrichtung) . 

RETTJRN - Anwe i s ung 

Ein aufgerufenes Regelprogramm fuhrt die RETURN-Anweisung aus, 
urn die Steuerung zuruck zu der aufrufenden Regel zu bringen. Die 
RETURN-Anweisung kann irgendwo in einem Progratnm plaziert 
werden. Der Regelsprachencodeerzeuger ordnet ein implizites 
RETURN am Ende jedes Regelprogramms an. 

Ubertragung von Daten zwiscben Regain 

Wie in dem vorangehenden Absclinitt bemerkt wurde, konnen Regeln 
hochstens einen Input -View und einen Output- view haben, die in 
dem Endlager definiert sind. Dies bedenkend gelten die folgenden 
Beschrankungen fur den FluS beim Ubertrag von Daten: 

Eine Regel kann iliren Input -View nicht andem, falls 
er nicht audi ihr Output ist (d, ti. INOUT) . 

Eine Regel kann nicht den Output-View eines Moduls, 
das sie aufruft, andern, falls er nicht das gleiche 
wie die Eingabe des Moduls ist. 

Eine Regel kann nicht ihren input-view mit demjenigen 
der Ausgabe ihres Nachfolgers teilen. Das Teilen von 
Views ist erlaubt zwischen Regeln desselben Levels, 
wenn die views dieselbe Verwendung haben (z. B. beide 
als Input) , 

Output-Views von Regeln und die Input-views von Modu- 
len, die sie auf rufen, werden beim Aufrufen geloscht, 
wie auch lokal erklarte views. 

mnwandlungsunters tiitzungss tnxkturen 

Die Fensterumwandlung (CONVERSE WINDOW) unterstutzt Kommunika- 
tion zwischen Regelprogrammen in der Personal Computer-umgebung 
und dem Benutzer eines Systems. 

Die Anweisung hat die Form: 

CONVERSE WINDOW WINDOW_NAME, 

wobei WINDOW_NAME der Name ist, der der Anzeige gegeben wurde, 
als sie in das HPS-Endlager eingegeben wurde. 

Es ist anzumerken, daS es einen Unterschied zwischen WlNDOW__NAME 
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und Fenster-View gibt . Jeder WINDOW_NAMB ist mit einem View 
verbunden, der sein Fenster-View genannt wird, Nicht jeder view 
in dem Endlager Icann als ein Fenster-view verwendet werden. Bin 
Fenster-View karin nur einen 01 Level, 03 Level und 05 Level 
haben. Es ist anzumerken, daS eine Regel mehr als eine 
Umwandlungsanweisung aufweisen kann, aber nie mehr als einen 
Fensternamen. Es ist auch anzumerken, daS nur Regain auf dem PC 
Utnwandlungsanweisungen aufweisen konnen. 

Asynchrone .ntitersbutzungsstrukturen 

Dieser Anhang faSt die Regelsprachenkonstrukte zusammen, die 
nicht angefragte Daten ausgebende Prozesse (UD) aufrufen. Nicht 
angefragte Daten erlauben es einer Regel, Daten zu einer anderen 
Regel zu senden, ohne daE die letzte Regel hiemach anfragt. 
Dies wird unterstutzt unter Verwendung der folgenden 
Anwei sungen : 

ASYNC ATTACH 
ASYNC DETACH 
ASYNC REFRESH 
ASYNC ROUTE 

Die folgende Diskusion bezieht sich auf eine Hardwarekonf igu- 
ration mit einer Architektur, die aus einem IBM Mainframe, der 
das CICS -Bet riebssys tern unterstutzt, einem Stratus Minicomputer 
und einer Reihe von PC-Arbeitsplatzen besteht.. Alle diese 
Konstrukte sind derzeit beschrankt auf Regeln auf dem PC. Es 
gibt auch Stratusunterroutinen, urn die folgenden Anweisungen 
auszufuhren. 

Beim Definieren des PC-Konstrukts werden wir die Existenz der 
folgenden Regelelementf alle annehmen: 



rpcl 


Eine 


PC-Regel, die das Fenster wpcl umwandelt 


rpc2 


Eine 


PC-Regel, die das Fenster wpc2 umwandelt 


rpc3 


Eine 


PC-Regel, die wpcl auffrischt 


rpc4 


Eine 


PC-Regel, die wpc2 auffrischt 


rstl 


Eine Stratus -Regel, die eine Komponente aufruft, 
welche die send_message Unterroutine verwendet. 



ASYNC ATTACH-ANWEISUNG 
Syntax 

Die ASYNC ATTACH -Anwei sung hat die folgende Form: 
ASYNC ATTACH RULE rpc3 VIA RULE rstl 
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Dieser Befehl startet den Empfang von nicht angefragter Eingabe, 
die von der Stratus-Regel rstl gesendet wird, durch die PC-Regel 
prc3 . 

Semantisclie Uberprufung 

ATTACH kann nur verwendet werden, falls: 

die Ausfuhrungsumgebung (Endlagerattribute der angeiiangten 
Regel) der PC ist und VIA RULE STRAT ist) . 

ASYHC DETACH -AKWEISUKG 
Syntatx 

Die ASYNC DETACH -Anwei sung hat die folgende Form: 

ASYNC DETACH RULE rpc3 VIA RULE rstl 

Dieser Befehlt fuhrt die exakte Umkehr von ATTACH aus . Er kann 
nur nach einem ATTACH-Bef ehl verwendet werden; zu seinem 
Zeitpunkt unterbricht er den Etnpfang von nicht angefragter 
Eingabe, die von der Stratus-Regel rstl gesendet wird, durch die 
PC-Regel rpc3 , , 

Semantische Uberpru£ung 

Dieselbe wie bei ATTACH. 

ASYNC ROUTE -Anwei sung 
Syntax 

Die ASYNC ROUTE -Anwei sung hat die folgende Form: 

ASYNC ROUTE RULE rpc3 VIA RULE rpc4 

Dieser Befehl schaltet den Vorgang des Auffrischens eines 
Fensters von der PC-Regel rpc3 auf die PC-Regel rpc4 urn. 

Semantlsche uberpriifung 

ROUTE kann nur verwendet werden, falls: 

die Ausfuhrungsumgebung (Endlagerattribute) von beiden Regeln 
der PC ist. 

AS'YNC REFRESH -Anwei sung 
Syntax 

Die ASYNC RE FRESH -Anwei sung hat die folgende Form: 
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ASYNC REFRESH WINDOW: wpcl 

( F I ELD Fe ld_Name 

VIEW View_Name 
OCCUR Feld__Occur 
BEEP 
FLASH) 

wobei wpcl ein Fenstername und Feld_Name, view_Name und 
Feld_Occur ein bestimmtes Feld in diesem Fenster identif izieren. 
Dieser Befehl leitet das automatische Aktualisieren des spezi- 
fizierten Felds fur so lange ein, wie die Regel angehangt ist. 

Sememtik 

Fur das folgende sei angenoramen, daB das Fenster wpcl einen 
Fenster- View wvl aufweist, der ein auftretendes Array VI 
enthalt; eine Listenbox, die ihrerseits Vi zugeordnet ist, 
umfafit ein Feld Fl . Der folgende Befehl: 

ASYNC REFRESH Fenster wpcl [REFRESH-Optionen] 

mit den REFRESH-Optionen BEEP xmd/oder FLASH wird ein Piep- 
Signal und/oder Aufleuchten der auf gef rischten Daten hervorge- 
rufen, Eine von beiden, beide Oder keine dieser Optionen konnen 
festgelegt werden. 

Andere REFRESH- Schlusselworte sind: 

1. FIELD Fl 
VIEW VI 
OCCUR I 

Resultat: Bei der Listenbox VI werden Fl Oder VI OF wvi 
auf gef rischt . 

2. FIELD Fl. 
VIEW VI 

Resultat: Jedes Auftreten des Felds Fl bei VI wird aufge- 
f rischt (d. h, die Spalte) . 

3. VIEW VI 
OCCUR I 

Resultat: In der Listenbox VI wird die i ' te Reihe aufge- 
f rischt. 

4 . VIEW VI 

Resultat: Die gesatnte Listenbox Vl wird auf gef rischt . 

Bei den Optionen 1 und 2 kann die VIEW-Klausel weggelassen 
werden, aber nur falls Fl von wvi einmalig in der Regel ist. 



Bei dem obigen 
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kann Fi der Literalname des Felds oder einer Variablen 
sein, die den Namen enthalt (d, h. es ist entweder ein 
Zeichen oder ein Feld vom Typ CHAR) 

kann Vl der Literalname des Views oder einer Variablen 
sein, die den Natnen enthalt (d. h. es ist entweder ein 
Zeichen oder ein Feld vom Typ CHAR) 

ist i entweder eine Ganzzahl oder ein Feld vom Typ INTEGER. 
Semant:isch.e Uberpriifung 

Die WINDOW-Klausel ist obligatorisch . 

Die VIEW-Klausel, falls angegeben, muE einen Unter- 
View des von der WINDOW-Klausel identif izierten Views 
angeben . 

Die FIEliD-Klausel, falls angegeben, muS einen Feld- 
namen spezif izieren, der in dem View enthalten ist, 
welcher von der VIEW-Klausel identif iziert wird. 

Falls OCCUR verwendet wird, mufi der von der VIEW- 
Klausel identif izierte view ein auf tretender View 
sein. 

Das OCCUR-Literal muS innerhalb von Grenzen liegen. 

Ridxtlinien betreffend die Verwendxuig von ASYNC 

Eine Regel kann nicht sowohl CONVERSE -Anweisungen als 
auch ASYNC- Anweisungen enthalten. 

Eine Regel, die umwandelt, kann keine Regel mit einer 
ASYNC -Anwei sung verwenden und umgekehrt. 

Einer Regel, der das im Endlager definierte Attribut 
ASYNC gegeben ist, ksmn keine USE ... NEST-Anweisung 
aufweisen (weil NEST impliziert, daS sie irgendwo in 
der Hierarchie der Regeln eine Regel mit einem 
CONVERSE aufruft oder in ihr selbst eine Regel mit 
einem CONVERSE vorhanden ist) . 

Jeder Fenster_Name ist einem View zugeordnet, genannt Fenster- 
View. Nicht jeder View in dem Endlager kann als Fenster-View 
verwendet werden. Ein WINDOW-View kann nur 01 Level, 03 Level 
und 05 Level haben. Es ist anzumerken, daS eine Regel mehr als 
eine CONVERSE -Anwei sung, aber niemals mehr als einen Fenster- 
Namen haben kann. Es ist auch anzumerken, daS nur Regeln auf dem 
PC CONVERSE -Anweisungen haben konnen. 
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Application NO. : 91 901 023.1 
Applicant: Seer Technologies, Inc. 

8000 Regency Parkway 

US - Gary, North Carolina 27511 



PATEMTAITSPRUCHE 

1. verfahren zum Betreiben eines Datenprozessors zum Erzeugen 
und verteilen eines Gomputerprograirans in einem Computersystem, 
das eine Mehrzahl von Hardwarekomponenten aufweist, die 
verbunden sind, urn ein zusammengeschaltetes Cotnputemetzwerk 
auszubilden, wobei Merkmale. die sich auf die Spezif ikation des 
Computerprogramms beziehen, in Form von Datenelementen und 
Datenbeziehungen spezifiziert sind, dadurch gekennzeiclmet s 

a. daS der Datenprozessor als Eingabe Daten akzeptiert, 
die sich auf eine von dem computerprogramm auszufuhrende 
Aufgabe beziehen, wobei die Eingabedaten gemaS einem vorau- 
sgewahlten Satz von Datenelementen charakterisiert sind, 
wobei diese Datenelemente vorausgewahlte Kategorien 
aufweisen, 

b- daS der Datenprozessor als Eingabe in den Datenprozes- 
sor , Inforroationen zum verkniipfen der Datenelemente gemafi 
einem vorausgewahlten Satz von Datenbeziehungen akzeptiert, 
wobei diese Datenbeziehungen vorausgewShlte identif izieren- 
de Eigenschaften zwischen den Datenelementen aufweisen, 

c. dafi der Datenprozessor arbeitet, um die Eingabedaten- 
elemente gemSS dem Eingabesatz der Datenbeziehungen mitein- 
ander zu verknupfen, wobei dieser verknvipfte Satz von 
Datenelementen und Datenbeziehungen ein Datenmodell fur die 
von dem Computerprogramm zu verwendenden oaten bildet, 

d. daS der Datenprozessor arbeitet, um den verknupften 
Satz von Datenelementen und Datenbeziehungen in einem 
Speicherbereich zu speichern, 

e. daS der Datenprozessor als Eingabedaten Prozessor- 
informationen iiber den Ablauf des Computerprogramms in der 
Form von Spezif ikationen fur ein hierarchisches ProzeS- 
modell akzeptiert, wobei das hierarchische ProzeSmodell 
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eine Darstellung aufweist, die die Funktion des CoTr4)uters 
in diskrete Aufgaben auf teilt, wobei die diskreten Aufgaben 
Beschreibungen der Funktionen vorausgewahlter Abschnitte 
des Computerprogramms und die Verarbeitungsanf orderungen 
fir das implementieren dieser Funktionen aufweist, wobei 
diese Beschreibungen zu einem vorausgewahlten Satz von 
ProzeBelementen gruppiert sind, wobei die Prozefielemente 
vorausgewahlte Prozefikategorien aufweisen, 

f . daS der Datenprozessor als Eingabe Inf ormationen zum 
verknupfen dieser ProzeSelemente gemaB einem vorausgewahl - 
ten Satz von Prozefibeziehungen akzeptiert, wobei diese 
ProzeSbeziehungen Beschreibungen aufweisen, um Abhangig- 
keiten zwischen den ProzeSelementen zu identif izieren, 

g. daE der Datenprozessor arbeitet, utn die ProzeSelemente 
gemaS dem vorausgewahlten Satz von ProzeSbeziehungen zu 
verknupfen, um das hierarchische Prozefimodul zu erzeugen, 

h, daS der Datenprozessor arbeitet, um das hierarchische 
ProzeSmodell in dem Speicherbereich zu speichem, 

i, daS der Datenprozessor als Eingabe Inf ormationen 
akzeptiert, die Verschaltungsdaten zu dem Computernetzwerk 
und Bet riebsanf orderungen an die. Betriebsumgebungen von 
vorausgewahlten Hardwarekomponenten spezif izieren, 

j . daS der Datenprozessor arbeitet, um die Verschaltungs- 
daten- und Betriebsanforderungsinf ormationen in dem 
Speicherbereich zu speichem, 

k, daS der Datenprozessor als Eingabe Inf ormationen zum 
Verknupfen der Verschaltungsdaten- und Betriebsanfor- 
derungsinf ormationen zu den Hardwarekomponeneten mit 
vorausgewahlten ProzeSelementen, um die Betriebsumgebung 
fur die Ausfuhrung von vorausgewahlten Prozel^elementen zu 
spezif izieren, akzeptiert, 

1. daB der Datenprozessor arbeitet, um die Verschaltungs- 
daten- und Betriebsanforderungsinf ormationen zu den 
Hardwarekomponeneten mit den vorausgewahlten ProzeB- 
elementen zu verknupfen. 



daB der Datenprozessor als Eingabe Inf ormationen 
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akzeptiert, die umgebungsunabhangige logische Konstrukte in 
einer ersten Programmiersprache aufweisen, wobei die 
Ipgischen Konstrukte Anweisungen in der ersten Computer- 
programmiersprache aufweisen, die es den Computerhardware- 
komponenten ermoglichen, die in vorausgewShlten entspre- 
chenden ProzeSelementen spezif izierten diskreten Aufgaben 
auszufuhren, wobei die erste Programmiersprache Anweisungen 
aufweist, die auf vorausgewahlte ProzeSelemente und den 
verknupften Satz von Datenelementen und Datenbeziehungen 
Bezug nehmen, 

n. dafi der Datenprozessor als Eingabe Inf omnationen 
akzeptiert, die jedes logische Konstrukt mit einem 
entsprechenden vorausgewahlten Prozefielement in Beziehung 
setzen, wobei das logische Konstrukt so ausgebildet ist, 
daiS es die Funktion, die durch sein entsprechendes ProzeS- 
element spezif iziert ist, ausfuhrt, 

o. daS der Datenprozessor arbeitet, urn gemaS den 
Beziehungsinf ormationen jedes logische Konstrukt mit einem 
entsprechenden ProzeSelement zu verknupfen, 

p. daS der Datenprozessor arbeitet, um die verknupften 
logischen Konstrukte und die entsprechende Eingabe, die die 
logischen Konstrukte mit einem ProzeSelement in Beziehung 
setzt, in dem Speicherbereich zu speichem, 
q, daS der Datenprozessor arbeitet,. um Computerprograram- 
module unter Verwendung der logischen Konstrukte, der 
entsprechenden vorausgewahlten ProzeSelemente , anderer 
vorausgewahlter ProzeSelemente des hierarchischen ProzeS- 
modells, des verkn^lpften Satzes von Datenelementen und 
Datenbeziehungen und der Eingabeinf ormationen, die die mit 
den vorausgewahlten entsprechenden ProzeSelementen 
verknupften Verschaltungsdaten zu den Hardwarekomponenten 
spezif izieren, zu erzeiigen, wobei die Computerprogrammodule 
jeweils einen Computercode aufweisen, der von der Betriebs- 
umgebung der Hardwarekomponente unterstutzt wird, die mit 
dem entsprechenden vorausgewahlten ProzeSelement verknupf t 
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2. verfahren nach T^spruch 1, weiteirhin dadurclx gekezm- 
zeicbnet: 

a, daS der Datenprozessor arbeitet, um den Speicher- 
bereich abzutasten, um jedes erzeugte Codemodul den 
verknupften Hardwarekomponenten zuzuordnen, und 

b, daS der Datenprozessor arbeitet , um jedes erzeugte 
Codemodul an die verknupften Hardwarekomponenten zu 
verteilen. 

3. verfahren nach Anspruch 1, weiterhin dadurch. gekennzeicli- 
net; daS jedes Computercodemodul ein Que 11 codemodul aufweist. 

4 . ^ verfahren nach Anspruch 2 , weiterhin dadurch gekennzeich- 
net: daS jedes Quellcodemodul an seine entsprechende Hardware- 
komponente verteilt wird. 

5. Verfahren nach Anspruch 4, weiterhin dadurch gekennzeich- 
net: daS jede Hardwarekomponente arbeitet, um ein Objektcode- 
modul fur jedes Quellcodemodul, das an die Hardwarekomponente 
verteilt wird, durch Kompilieren des Quellcodemoduls zu 
erzeugen . 

6. Verfahren nach Anspruch 3, weiterhin dadurch gekenn- 
zeicbnet : 

a. daS der Datenprozessor arbeitet, um Objektcodemodule 
fur das Computerprogramm durch Kompilieren jedes Quellcode- 
moduls zu erzeugen, und 

b. daS jedes Ob jekt codemodul an seine entsprechende 
HardwarekoTt5>onente verteilt wird. 

7. Verfahren nach Anspruch 3, weiterhin dadurch gekeimzeich- 
net, dafi der Quellcode Anweisungen in einer zweiten, hoheren 
Computerprogrammiersprache auf weist . 

8. Verfahren nach Anspruch 3, weiterhin dadurch gekennzeich- 
net, daS der Quellcode Anweisungen in einer Programmiersprache 
der dritten Generation auf weist, die von der Betriebsumgebung 



einer vorausgewahlten Hardwarekomponente unterstutzt wird. 

9. Verfahren nach Anspruch 1, weiterhin dadurcli gekennzeich- 
net, daS der Quellcode Anweisungen in COBOL aufweist. 

10. Verfahren nach Anspruch 1, weiterhin dadurch gekexmzeich- 
net, daS der Quellcode Anweisungen in C aufweist. 

11. Verfahren nach Anspruch l, weiterhin dadurch gekennzeicb- 
net, daS jedes Computercodemodul ein Ob j ektcodemodul aufweist. 

12. verfahren nach Anspruch 3, weiterhin dadurch gekenn* 
zeichnet; 

a. daS der Datenprozessor arbeitet, um jedes der 
erzeugten Quellcodemodule zu kompilieren und um ein 
entsprechendes Ob j ektcodemodul zu erzeugen, das in der 
Betriebsumgebung der vorausgewahlten entsprechenden 
Hardwarekomponente ausfuhrbar ist, und 

b. daS der Datenprozessor arbeitet, um jedes erzeugte 
Ob j ektcodemodul mit einem vorausgewahlten anderen 
Ob j ektcodemodul gemaE der ProzeSbeziehung, die durch das^ 
hierarchische ProzeSmodell spezif iziert ist, zu verknupfen. 

13. Verfahren nach Anspruch 1, weiterhin dadurch gekenn- 
zeichnet : 

a. daS ein Computercodekomponentenmodul in einem Daten- 
prozessor vorgesehen ist, der konfiguriert ist, um eine 
vorausgewShlte Funktion auszufuhren, und der zum Ausfuhren 
(der Funktion) in den Betriebsumgebungen von vorausgewahl- 
ten Hardwarekomppnenten geeignet ist, 

b. da6 vorausgewahlte Komponentenelemente in dem hierar- 
chischen ProzeSmodell vorgesehen sind, die die Funktions- 
und Betriebsanf orderungen der Objektcodekomponentenmodule 
beschreiben, 

c. daB der Datenprozessor arbeitet, um jedes Komponenten- 
element mit seinem entsprechenden Computercodekomponenten- 
modul zu verknupfen, 
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d. daS das computercodekotnponentenmbdul in einem Speicher 
in vorausgewahlten Hardwarekomponenten gespeichert wird, 

e. daB die ProzeEel entente, die die KotniJonenten und die 
auf die entsprechenden Coraputercodekon5)onentenTnodule Bezug 
nehmenden Verkniipfungsinf ormationen beschreiben, in dem 
Speicherbereich gespeichert werden, 

f. daS Inf ormationen zum Verknupfen jedes Komponenten- 
elements mit einem vorausgewahlten ProzeEelement in dem 
hierarchischen ProzeBmodell als Eingabe in den Daten- 
prozessor akzeptiert werden und. 

g. daE der Computer arbeitet, urn jedes Komponentenelement 
mit einem entsprechenden vorausgewahlten ProzeSelement in 
dem hierarchischen ProzeSmodell zu verknupfen. 

14. Verfahren nach Anspruch 13, weiterhin dadurch gekennzeich- 
net. daS der Datenprozessor als Eingabe vorausgewahlte Anweisun- 
gen in der ersten Con?)utersprache akzeptiert, die auf die 
Computercodekomponentenmodule Bezug nehmen, 

15. Verfahren nach Anspruch 13, weiterhin dadurch geXeimzeich- 
net^ daE der Datenprozessor als Eingabe vorausgewahlte Anweisun- 
gen in der ersten Computer spr ache akzeptiert, die auf die 
KOTcponentenelemente Bezug nehmen. 

16. verfahren nach Anspruch 13, weiterhin dadurch gekennzeich- 

net, daS das Computercodekomponentenmodul Objektcodeanweisungen 
aufweist, wobei die Objektcodeanweisungen zur Ausfuhrung in 
einer Betriebsumgebung einer entsprechenden Hardwarekomponente 
geeignet sind. 

17. Verfahren nach Anspruch 13, weiterhin dadurch gekexmzeich- 
net, daB das Computercodekomponentenmodul eine graphisch 
gestutzte Benutzerschnittstellenfunktion ausfuhrt. 

18. Verfahren nach Anspruch 13, weiterhin dadurch gekennzeich- 

net. daS das Computercodekomponentenmodul den Transfer von Daten 
zwischen zwei vorausgewahlten objektcodemodulen ausfuhrt. 
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19. Verfahren nach Anspruch 13, weiterhin dadurch gekennzeicti- 
net, daS das Computercodekomponentenmodul den Transfer von Daten 
zwischen zwei vorausgewahlten Computercodemodulen ausfuhrt, die 
vorgesehen sind, in den Betriebsumgebungen von zwei verschie- 
denen Hardwarekomponenten zu arbeiten. 

20. Verfahren nach Anspruch 2, weiterhin dadurcli gekenn-. 
zeicbnek: 

a. daS der Datenprozessor als Eingabe Sicherheits- 
zugangseingabedaten akzeptiert, die Inf ormationen daruber 
aufweisen/ welche Benutzer Zugang zu dem Computerprograiran 
und welche vorausgewahlten Hardwarekomponenten Sicherheits- 
freigaben zuin Ausfiihren des Computerprogranims haben, und 
b- dafi der Datenprozessor arbeitet, um die Verteilung der 
Computercodemodule an die vorausgewahlten Hardwarekompo- 
nenten gemaS der Sicherheitszugangs eingabe zu beschranken. 

21. Verfahren nach Anspruch 20, weiterhin dadurch gekennzeich- 
net, daS der Datenprozessor arbeitet, um den Benutzern den 
Zugang zu dem Computerprogramm geraaS der Sicherheitszugangs- 
eingabe zu erlauben. 

22. Verfahren nach Anspruch 2, weiterhin dadurcli gekenn- 
zeichnet: 

a. daS der Datenprozessor als Eingabe Inf ormationen zum 
Mddifizieren der in der ersten Cottiputerprograramiersprache 
gehaltenen Anweisungen eines logischen Konstrukts 
akzeptiert, 

b. daS der Datenprozessor arbeitet, um den Speicher- 
bereich zu durchsuchen und um f estzustellen, ob die 
Modifikation Anderungen der verknupften Elemente in dem 
hierarchischen ProzeSmodell erforderlich macht, 

c. daE der Datenprozessor arbeitet, um neue Computer- 
programmodule unter verwendung der modif izierten logischein 
Konstrukte, der entsprechenden vorausgewahlten ProzeS- 
elemente, anderer vorausgewahlter ProzeSelemente des 
hierarchischen ProzeSmodells, des verknupften Satzes von 
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Datenelementen und Datenbeziehungen und der Eingabeinfor- 
tnationen, die die mit den vorausgewahlten entsprechenden 
ProzeSelementen verknup.f ten Verschaltungsdaten zu den 
Hardwarekomponenten spezif izieren, zu erzeugen, und 
d. daS der Datenprozessor arbeitet, um die neuen 
Coraputerprogrammodule an die Betriebsumgebungen der 
entsprechenden vorausgewahlten Hardwarekomponenten zu 
verteilen. 

23. Verfahren nach Anspruch 22, weiterhin dadurch gekennzeich- 
netr dae die neuen Cotnputercodemodule an die Hardwarekomponenten 
gemaE der Sicherheitszugangseingabe verteilt werden, wobei die 
Sicherheitszugangseingabe Inf ormationen daruber aufweist, welche 
Benutzer Zugang zu dem Computerprogramm und welche vorausgewahl- 
ten Hardwarekomponenten Sicherheitsf reigaben zum Ausfuhren des 
Computerprograrams haben . 

24 . Verfahren nach Anspruch 2 , weiterhin dadurch gekenn- 
zeicbnet ; 

a. daS der Datenprozessor als Eingabe Inf oxmationen zum 
Modifizieren der in vorausgewahlten Prozefielementen Oder 
ProzeSbeziehungen zwischen zwei Prozefielementen enthaltenen 
Daten akzeptiert, 

b. daS der Datenprozessor arbeitet, um den Speicher- 
bereich zu durchsuchen, um f estzustellen, ob die 
Modifikationsinf ormationen Anderungen von verknupften 
logischen Konstrukten er f order lich machen, 

c. daS der Datenprozessor arbeitet, um Modif ikationen an 
den verknupften logischen Konstrukte auszufiihren, die durch 
die Anderungen der vorausgewahlten ProzeSelemente erf order- 
lich gemacht wurden, 

d. daS der Datenprozessor arbeitet, um neue Computercode- 
module unter Verwendung der modif izier ten logischen 
Konstrukte, der entsprechenden vorausgewShlten ProzeS- 
elemente, anderer vorausgewahlter ProzeSelemente des 
hierarchischen ProzeSmodells , des . verknupften Satzes von 
Datenelementen und Datenbeziehungen und der Eingabe- 
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inf ormationen, die die mit den vorausgewahlten ent- 
sprechenden Prozefielementen verknupf ten Verschaltungsdaten 
zu den Hardwarekomponenten spezif izieren, zu erzeugen, und 
d. daS der Datenprozessor arbeitet, um die neuen 
Coraputerprogrammodule an die Betriebsumgebungen der 
entsprechenden vorausgewahlten Hardwarekomponenten zu 
verteilen. 

25. verfahren nach Anspruch 24, weiterhin dadurcli gekenn- 
zeichnet: 

a. daS der Datenprozessor arbeitet, um den Speicher- 
bereich zu durchsuchen, um f estzustellen, ob die Modifika- 
tionsinf ormationen Anderungen des verknupften Satzes von 
Datenelementen und Datenbeziehungen erforderlich machen, 
und 

b. daS der Datenprozessor arbeitet, um Modif ikationen an 
dem verknupften Satz von Datenelementen und Datenbeziehun- 
gen auszufuhren, die durch die Anderungen der vorausgewahl- 
ten ProzeSelemente erforderlich gemacht wurden. 

26- verfahren nach Anspruch 2, weiterhin dadurch gekenn- 
zeichnet: 

a. daS der Datenprozessor als Eingabe Inf ormationen zum 
Modifizieren der in vorausgewahlten Datenelementen oder 
Datenbeziehungen zwischen zwei Datenelementen enthaltenen 
vorausgewahlten Kategorien akzeptiert, 

b. daS der Speicherbereich durchsucht wird, um festzu- 
stellen, ob die Modifikation Anderungen der verknupften 
logischen Konstrukte oder des hierarchischen ProzeEmodells 
erforderlich macht, 

c. daS der Datenprozessor arbeitet, um den Speicher- 
bereich zu durchsuchen, um f es t zus tellen, ob die 
Modifikat ions inf ormationen Anderungen des verknupften 
Satzes von ProzeSelementen und ProzeSbeziehungen in dem 
hierarchischen ProzeSmodell erforderlich machen, 

d. daS der Datenprozessor arbeitet, um Modif ikationen an 
dem verknupften Satz von ProzeSelementen und ProzeS- 
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beziehungen auszufuhren, die durch die Anderungen der 
vorausgewahlten Datenelemente und Datenbeziehungen des 
verknupf ten Satzes von Datenelementen und Datenbeziehungen 
erforderlich gemacht wurden, 

e. daS der Datenprozessor arbeitet, um Modif ikationen an 
den verknupften logischen Konstrukten auszufiihren, die 
durch die Anderungen der vorausgewahlten Datenelemente und 
Datenbeziehungen des verknupften Satzes von Datenelementen 
und Datenbeziehungen erforderlich gemacht wurden, 

f. daS der Datenprozessor arbeitet, um neue Computer- 
codemodule unter Verwendung der modif izierten logischen 
Konstrukte, der entsprechenden vorausgewahlten ProzeE- 
elemente, anderer vorausgewahlter ProzeSelemente des 
hierarchischen Prozefimodells , des verknupften Satzes von 
Datenelementen und Datenbeziehungen und der Eingabe- 
informationen, die die mit den vorausgewahlten ent- 
sprechenden ProzeSelementen verknupften Verschaltungsdaten 
zu den Hardwarekomponenten spezif izieren, zu erzeugen, und 

g. daS der Datenprozessor arbeitet, um die neuen Compu- 
tercodemodule an die Betriebsumgebungen der entsprechenden 
vorausgewahlten Hardwarekomponenten zu verteilen. 

27. Verfahren nach Anspruch 1, weiterhin dadurch gekezm- 
zeichnet : 

a. daS der Datenprozessor als Bingabe zusatzliche 
Informationen akzeptiert, die sich auf den Ablauf eines 
zweiten Compute rprogramms beziehen, 

b. daS der Datenprozessor arbeitet, um den Speicher- 
bereich nach Gruppen von bereits in dem Speicherbereich 
existierenden ProzeSelementen und ProzeBbeziehungen zu 
durchsuchen, die dem gewunschten Ablauf des zweiten 
Computerprograrams ahnliche ProzeSfunktionen beschreiben, 

c. dajS der Teil des hierarchischen Prozefimodells und der 
logischen Konstrukte und Computermodule , die dem gewunsch- 
ten Ablauf des zweiten Computerprogramms ahnliche Prozefi- 
funktionen beschreiben, wiederverwendet werden. 



28. Verfahren nach Anspruch 27, weiterhin dadurdi gekenn- 
zeichnefc: 

a. daB der Datenprozessor als Eingabe zusatzliche 
informationen akzeptiert, die sich auf die Funktion des 
zweiten Computerprograinms be Ziehen, 

b. daB der Datenprozessor arbeitet, urn die zusatzliche 
infonnation zu den entsprechenden wiederverwendeten ProzeS- 
elementen des hierarchischen Prozefimodells hinzuzufugen, 
und 

c. daS der Datenprozessor arbeitet, um die ProzeS- 
elemente. die die zusatzlichen, sich auf deii Ablauf des 
zweiten cotnputerprogramms beziehenden Informationen 
enthalten, in dem Speicherbereich zu speichem. 

29. Verfahren nach Anspruch 27. weiterhin dadurcli gekenn- 
zeiclmet:: 

a. dcdS der Datenprozessor als Eingabe zusatzliche Infor- 
mationen akzeptiert. die sich auf die Funktion des zweiten 
Computerprogramms beziehen, wobei die Informationen gemaS 
neuen prozeBelementen des vorausgewalilten Satzes von 
ProzeSelementen spezifiziert sind, 

b. daS der Datenprozessor als Eingabe Daten zum verknup- 
fen jedes neuen prozefielements mit einem oder thehreren 
andereri neuen oder existierenden ProzeSelemente (n) durch 
eine ProzeSbeziehung des vorausgewShlten Satzes von 
Prozefibeziehuhgen akzeptiert, 

c. daS der Datenprozessor arbeitet, utn jedes neue 
ProzeBelement rait einem oder mehreren anderen neuen oder 
existierenden ProzeSelemente{n) durch eine ProzeBbeziehung 
des vorausgewahlten Satzes von ProzeBbeziehungen zu 
verknupfen, um ein neues hierarchisches ProzeSmodell zu 
erzeugen, und 

d. dafi das neue hierarchische ProzeBmodell in dem 
Speicherbereich gespeichert wird. 
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30. Verfahfen nach Anspruch 29, weiterhin dadurcti gekenn- 
zelcbnet:: 

a. dafi eine einer vorausgewahlten Hardwarekomponente 
entsprechende Betriebsuragebung fur jedes neue logische 
Konstrukt spezifiziert wird, 

b. daS der Datenprozessor arbeitet, urn die in der ersten 
Prograramiersprache gehaltenen Anweisungen in jedem neuen 
logischen Konstrukt, den entsprechenden vorausgewahlten 
ProzeSelementen, anderen vorausgewahlten Prozefielemeriten 
des hierarchischen Prozefimodells, dem verknupften Satz von 
Datenelementen und Datenbeziehungen und den Eingabe- 
inf ormationen, die die mit den entsprechenden voraus- 
gewahlten Prozefielementen verknupften Verschaltungsdaten zu 
den Hardwarekomponenten spezif izieren, zu verwenden, und 

c. daS der Datenprozessor arbeitet, um die neuen 
Computerprogrammodule an die Betriebsumgebungen der 
entsprechenden vorausgewahlten Hardwarekomponenten zu 
verteilen. 

31. Verfahren nach Anspruch 1, weiterhin dadurch gekexmzeich- 
net^ daS jeder der Schritte a bis q in einer der Hardwarekon^o- 
nenten ausgefuhrt wird. 

32. Verfahren nach Anspruch 30, weiterhin dadurch gekexmzeich- 
net, daS jeder der Schritte a bis c in einer der Hardwarekompo- 
nenten ausgefuhrt wird. 

33. Verfahren nach Anspruch 1, weiterhin dadurch gekennzeich- 
net, daS der Speicherbereich eine relationale Datenbank 
aufweist, die in einer vorausgewahlten Hardwarekomponente 
angeordnet ist. 
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